On 4 Jul 2016 18:39:55 GMT, Bob Eager declaimed the following:
While the Sigma did have index capability (using registers 1-7; 0 encoded no indexing), it also supported one-level indirect addressing -- in which the data being loaded was retrieved via an address stored at the address in the operation. So one could work arrays via the complex of:
LD, Start_of_Array ADD, Offset LD, * ;* means indirect address
vs
LD, Offset LD, Start_of_Array,
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
I don't know about that, but the Burroughs mainframes had "tagged memory", each memory word (48 bits) had some extra bits to indicate the type of data stored in that memory location.
This was cleverly used all over the system. There was no need for separate instructions for integer or floating point operations, the same add instruction would just operate on whatever data was handed to it (including de-referencing of pointers).
Of course, what was most impressive was the sheer size and power consumption of this thing. A system usually consisted of 2 or 3 CPUs, a memory cabinet (6MB), 2 IO processors, all of them housed in cabinets as big as 2 19" racks alongside, plus of course a number of magtape drives and a number of diskdrives containing 2x200 Megabytes of disk storage in each cabinet the size of a washing machine. The system where I worked had about 7GB of disk storage.
A CPU cabinet held a large number of parallel powersupplies delivering a total current of about 5000A (about 30kW) to the processor. Compare that to a Raspberry Pi (which has more CPU performance). Stories were told about a worker that had inadvertently shorted the supply rails, hefty copper bars running alongside the cabinet.
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.
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.
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.
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.
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.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
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...
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).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.