Is it a lost cause?

I suspect I'd have more luck with our data center if anybody can remember where the paper docs got stored. Bitsavers is spotty--while they have some old stuff their collection is far from complete. Really more effort than I want to put into it either way. If I actually had a need to connect paper tape to the Z it would be a different story.

That's because someone like you came along and hacked the code and didn't alter the pseudo code.

If you have a bug the first thing to do is to examine the pseudo code. Is it actually meeting the specification?

If not fix it.

The does the actual code perform the functions outlined by the pseudo code?

If not, fix the code.

Its called coding discipline. IN a small project you can get away without it. When any random idiot out of a thousand may be called upo9n to fix the bug, possibly even in acceptance testing, then its the only way to get the bug fixer up to speed.

Its how you employ average coders and get results.

Guilty as charged, barely out of my first half century.

I see. Thank you I had not been aware of that stage of the evolution of instruction sets.

That's why I brought in the self extending concept, to my eye there's a substantial difference between adding new code and changing the code that's there.

Any clear and accurate description of what the code is supposed to achieve is good as far as I'm concerned. What I don't want to see in comments is a reiteration of the code, I want the intention and preferably in a sufficiently different form to the code that it doesn't contain the same errors. That's what I strive to provide when I comment code.

Of course. But not all processors have had stack pointers, not all processors have had index registers, and the PC can't be used to access data in a useful way (at least for arrays, I am aware of the PDP-11 etc.).

One of the more successful early CPUs did not have an index register, did not have a stack pointer, and had no way of using the PC to access data. It did have a way to do serial access to array elements.

Just seen this. Sory, I also replied. You will guess the CPU to which I am referring (I have two downstairs!)

You really don't like to be wrong, do you? Goalposts moving.

That CPU was not originally built out of TTL.

Yes.

Looks relatively current to me. z/OS in the title. I should mention that the subject was needing separate code. BTAM open looks something like other opens, same with read/write/close, but usually more operands and things like polling or flow control have to be addressed. The DCB for BTAM varies a lot. Even though I see DSORG=CX in the JCL DD statement, I doubt that would let you take a routine reading mag tape and make it read paper tape by changing the JCL.

So what was it built out of?

Either transistors or DTL--I'm seeing two versions of the story.

I recall using paper tape on a TTY, but I believe we just turned it on and off manually, and to the computer it was the same as typing on the keyboard or printing a file.

A lot of newbies will code something like this in assembler: L 12,A Load A into register 12 (where the comment just days what the instruction is doing)

A lot of processors didn't have stack pointers until quite late, e.g. all the ICL 1900 mainframes. I think the IBM S/360 and S/370 may not have had them either.

PDP-8 and many others of the same generation (HP 2114/2116, Honeywell DDP 112, DDP 316, DDP 516 and others) stored the subroutine return address into the first word of the subroutine. The first subroutine instruction was in the next word. The return from the subroutine was done with an indirect jump via the link location.

There was a pair of stack handling subroutines for PDP-8, about a dozen instructions each.

That sort of mindless comment is and always was useless, but it obviously got written into the house style, along with the mandatory comment on every line whether needed or not. TSC, who wrote the FLEX OS for 6800 and

INX Bump the X register

which was odd because in other respects their code read very well and had useful comments. FLEX and FLEX09 (for 6800 and 6809 respectively) were CP/M equivalents but with an even simpler and less arcane command language.

I was once taught to do that (about the same time I was taught to use a flowchart template).

It will give you surprisingly little.

The vast bulk of compiler bugs today are either in the lexing/parsing, and these will normally reject valid code; or they are in the optimisation.

gcc has more than 180 different optimisations, almost all of which can be turned on or off at will. They are grouped into 0, 1, 2, g, and s; where 0 is (almost) all off, 1 low level optimisation, 2 pretty aggressive, g debug-compatible, and s optimize for space.

And there are so much source code out there that the compilers are tested on; they are pushed through huge tests just there.

And I haven't been bitten by a compiler bug in decades.

-- mrr

That must have been fun when writing recursive subroutines or re-entrant code (e.g. calling subroutines from interrupt handlers)...

My first experience studying the architecture of a larger system was with the Burroughs B7700. This system was completely stack oriented, with display registers for algol compatible variable scope.

Mia culpa... it is COMPUTED GOTO. There are a couple of COMPUTED GOTO's in the FORTRAN IV code for Colossal Cave Adventure... that dispatches the commands to the right section of code. Even BASIC has a form of COMPUTED GOTO, but *not* ASSIGNED GOTO.

I guess I chose the ASSIGNED GOTO because I had *never* used it before, and I have *never* used it since. ISTM that ASSIGNED GOTO is *no* longer supported since FORTRAN 90... (It is *not* just depricated... it's