Is it a lost cause?

I remember that. The reasons for using a stack architecture mainly were:

- easy to write compilers for high-level languages

- compact instructions (zero-address) save memory

But indeed the performance suffers, especially in simple implementations.

Or any stack instructions. The functions of a stack were performed on OS/360 by a chain of register saveareas maintained mostly by software. I believe VM handled things differently, but I'm not sure exactly how.

I believe I actually did a small flowchart within the past couple of years

- it was a particularly complex piece of code and I wanted to be sure I'd covered all the options.

The caller provided a register save area pointed to by reg 13. Reg 15 had the address of the called routine, reg 14 the return address of the call. On entry to the subroutine the callers regs were saved in the area pointer to by reg 13.

Enhancements are not in the pseudo code

VM was (and is) a virtual machine system, so its programming environment is what the hardware gives you, plus a bunch of stuff implemented via trapping reserved instructions that handle shared memory, the virtual card chutes from one machine's simulated punch to another's reader, and the like.

For interactive use the usual environment was CMS, a single user monitor that provded a software environment similar enough to OS that it could run the same compilers.

Yeah. I have to say I didn't bother with early computers. expensive and not much use.

Core store. I mean. Really.

So about what an entry level 50c PIC has.

They should be

CNC machines used paper tape well into the 80s. I suspect offline machines converted punched cards or tape to paper tape. Later model FACET paper tape punches are rather intelligent and programmable for end-of-line handling, etc. which is ideal for offline copying & translation.

One of the 2 IBM 1130s I used around 1980 at the Cooper Union had the paper tape punch but no tape reader. I never got around to interfacing the Tally paper tape reader from the LGP21 to the 1130: they seemed indentical with 48v solenoids for tape motion, 8 star wheels to mechanically read the tape. Both 1130s had the 1442 card reader/punch, which were a pleasure to use.

-- jeffj

...

D'oh! That makes sense. thank you for the clarification.

-- jeffj

Yeah that's tricky, is all modification self modification.

Right up to the moment some wazzock put a deck in with a damaged card, the slightest kink on the leading edge of a card pretty much guaranteed that two or three cards would be shredded and spread throughout the inner workings, many of use became proficient with the card saw.

Our 1130 was replaced by an Eclipse and the 1442 with a table top card reader that used an air jet to fan the bottom of the stack instead of a precision 1.00000000000001 card thickness slot. The demo was impressive, one card in the deck was removed, crumpled, roughly flattened and put back in the deck. When it went through there was a sort of gulping sound but no read error, and no mess of shredded cards to sort out.

The perfect card reader - pity it was just in time for us to stop using cards, the Eclipes was multi-user, had terminals and plenty of disk.

All the IBM Mainframe "VM" operating systems consist of at least two operating systems.

CP which is often called VM, which is there to provide virtual Machines. Originally these were pretty basic Virtual Machines which looked exactly like a real S/370 to any program running in them.

Internally CP has a large number of control blocks which are chained together to manage the real hardware, the virtual machines and virtual hardware, and how they are mapped. I am not aware of any stack.

There is some use of OS type register save areas.

traditionally, when used to provide an interactive computing environment, CP was used to provide each used with a Virtual 370.

The user then loads the CMS Operating system into the VM. CMS is a single user operating system that provides a native CMS environment and DOS and OS emulated environments. Internally it uses OS style call/save/return mapping.

I don't believe that modern Z hardware has a hardware stack. There are still no PUSH/POP type instructions. For languages that need a stack generally a stack area is allocated when a program is loaded and one of the 16 General Purpose Registers is then used as a stack pointer, but in general it has to be incremented/decremented by a second instruction...

Dave G4UGM

One of the topics in this group,is how much work got done with computers that would be laughable today. 360s got us to the moon and back. PDP8s were the backbone of a lot of laboratories, publications, etc.

On the Plessey S250 each subroutine had its own block. The entire block was moved and the 3 word entry in the system table updated. All addresses were offsets down the block. The start offset lived in a special capability register. Unfortunately the operating system was hopeless at updating the global system table.

You must have a memory drop - the Nova architecture put return address into register 3, which was the other register able to be used with indexing (the other was register 2).

CP/M was mire than enough too run most businesses off and type letters on.

A PC running SCO unix was fine for up to around 50 terminals run9ing a database, several printers, text processing, and even a basic spreadsheet.

Really?!! I wonder if that's because there's one kind CPU in the world.

/BAH