Simulating the IBM 360/50 mainframe from its microcode
righto.com
righto.com
Anyway the 50 was the first computer I was paid to program on. Many were bought to run in 7070 emulator mode as the 50 was the smallest / cheapest machine that could run 7070.
Happily I was on the 360 side.
At another shop, we had 2 50s, one running DOS and the other OS with HASP.
One day a student was having trouble with the Test and Set (superceded by Compare and Swap) instruction not setting the condition code properly. I wrote a short diagnostic program to exercise TS, store the resulting condition codes and dump. The instruction was not performing correctly.
I showed the dump to the non IBM engineers who hemmed and hawed. A couple days later one phoned me up to say that TS wasn't setting the condition code correctly - exactly what I had been telling him.
They fixed the problem. The next day I got a phone call that HASP wasn't starting on the other 50. Took a dump and found HASP was in a wait just after TS.
The engineers had swapped microcode cards between the two machines.
My manager was not pleased with the engineers.
That's a good joke. Thanks for sharing.
>"I wrote a short diagnostic program to exercise TS, store the resulting condition codes and dump."
I had to look up HASP, which is an interesting bit of history. What were the IO devices that you spooled from?
Remember that JES2/3 were running batch jobs. TSO was shiny new.
SYNCH is how user mode exits are called from supervisor code.
COLT (Canadian On Line Teller) often ran (runs?) in supervisor state and in the bank I was working at the time would initialise a transaction buffer by setting it to all one's - very bad news when that buffer address was erroneously set to zero because some registers were not preserved across pseudo reentrant (a particularly repulsive term) interrupt points.
This invalidated all the New PSWs triggering an interrupt cascade such that the STOP key would not work because the instruction never completed. SYSTEM RESET (courtesy the IBM engineer) did the job.
Nowadays it's worth mentioning that that "DOS" has nothing to do with MS-DOS/PC-DOS on PCs (or any other DOS on any other microcomputer where the names may coincide).
The release dates of the IBM PC and System/360 being closer together than the IBM PC is old today, and the mainframe world being so secluded from mainstream computing, I wouldn't be too surprised if someone thought there were s/360s with an "A:\>" prompt on a teletype somewhere. :)
To the rest of the story, I cannot find the original quote no matter how I search (I'm sure it's out there, Google has just become increasingly worse lately), but I remember a story in a single paragraph of someone who contacted CDC or IBM or whatever, about a seemingly misbehaving instruction. The engineers replied that this was curious, as the instruction in question was usually one of the more stable instructions. That day, the person asking learned that apparently, machine code instructions can be ordered by reliability.
Great computing joke, love it.
IBM still sells emulators, now software-based, for companies that do mainframe software development. And they are freakishly expensive.
That was deliberate and made a lot of sense. The functionality was split between two programs. The VM/370 part emulates the raw machine. CMS is the "operating system" on top of the VM "hardware".
EBCDIC you'll only encounter in the mainframe and midrange world, and it's indeed sobering to realize that its encoding makes perfect sense on punchcards, but none whatsoever on any more modern medium.
When I was at IBM, we were making x86-based appliances for business software. I thought it would be cool if they used a mainframe CPU instead of x86 for them. It would have been slower, but possibly more reliable. Definitely it could have had some marketing cachet.. On the other hand, we otherwise did not want to eat our own dog-food.
IBM had Nick Treddenick, the lead designer of the 68K do the work. His book "Microprocessor Logic Design" covers the development of the "Micro/370" in great detail, including flow charted microcode that looks remarkably similar to the flowcharts in Ken's article (though apparently Treddenick used flowcharts for the 68K microcode prior to moving to IBM. Regrettably I haven't actually read through my copy yet, so I can't give any further details.
Ken, if you see this I highly recommend tracking down a copy to read, I think it's right up your alley.
There was a strange time in the early 1980s that every computer manufacturer feared obsolescence but machines like the Apple ][ kept selling because there wasn't a path for continuous improvement. Microcomputers at the time were all built around the video display system so you couldn't drop in a 10% faster CPU.
Intel didn't have a clear plan for the 8086, in fact they expected the future to be the doomed i860 or iAPX 432. They stumbled into the 24-bit 80286 which was "brain damaged" in terms of it's memory protection model but just plain kicked ass in performance. I bought a 12 MHz 286 machine in 1987 which was by far the best computer I ever owned, powerful enough that I could emulate the Z80 and use it as a software development workstation for CP/M. That was when the PC crushed everything else.
I could afford a 32-bit 486 and run Linux on it in 1993, and 10 years later I upgraded to a 64-bit version of the architecture.
Like the 360/370/390/z-Architecture the Microsoft-centric PC maintained instruction set compatibility over the years. Yet, that's not the only path to a sustainable computing brand. Apple started the mac on the doomed 68k, switched to Power PC, switched again to Intel, and switched again to ARM.
Microsoft tested the waters for such a migration multiple times but it's never amounted to much.
Sometimes I dream of a world where Apple didn't abandon the ][, released the //gs a few years earlier than it did, and eventually came out with a 32-bit extension of the 6502 architecture.
Microsoft could have tried to make MS-DOS portable similar to CP/M or UNIX, but it would be a big what-if regarding Amiga, Atari, Mac, Archimedes and UNIX market.
On paper the 68k was an attractive machine with lots of registers and the ability to access more memory in a more comfortable way than the low-cost microcomputers (that added bankswitching to evade the 64k limit in later iterations) and the IBM PC (which had a segmentation scheme that in some ways annoying but can also be a lot of fun for the assembly language programmer)
In practice there must have been something wrong with the 68k because even Motorola gave up on it and all of the computer lines based on it either went extinct or made a transition to RISC architecture (Apple to Motorola's Power PC, Sun to SPARC.)
I'd love to hear the real story of why Motorola abandoned the 68k.
I wouldn't say they abandoned the architecture, it just wasn't a PC chip. They did try a modernized version with Coldfire, but the original 68K line found a home in PDAs and embedded. DragonBall was pretty successful. The 68K ended up in the non-PC market because most of their customers jumped to RISC and they didn't execute the jump successfully enough to attract customers. Sun had SPARC and HP had PA/RISC.
For a while the 680x0 in Macs, Amiga and Atari was the most popular CPU, and I'm sure the first HPUX workstation I used in my Uni. had a 68040 so even in Unix and NeXT workstations.
But after the 68040 it never seemed to evolve into anything else, and probably got subsumed by the Power line of CPUs into oblivion.
And it has a fantastic assembly language to boot.
You wouldn't happen to know where more documents than what's on bitsavers exist for the 360/91 (or related like the 95 and 195) do you? Competing anecdotes are less than satisfying. My source has been worng before but he bats a pretty good average for his contrarian comparch statements.
It unfortunately doesn't seem to disambiguate the specific question of if floating point execution units were implemented via microcode unless I'm missing it.
That lines up with my source who started his career doing simulation and analysis of rocket propellent in micro gravity for the tail end of the Apollo program and some of the initial work for the space shuttle.
The Model 95 was the even more rare version with thin-film memory instead of core memory. Only two of them were produced, for NASA.
The Model 195 was a reimplementation of the Model 91 with "monolithic" integrated circuits instead of hybrid SLT modules. The System 370/195 was very similar to the System 360/195. Curiously, the System 360/195 has the black styling of System/370 control panels, rather than the beige control panel of System/360.
https://en.wikipedia.org/wiki/IBM_System/360_Model_91#Models...
The machines (were and maybe still) are optimized to run COBOL, and what COBOL programs are commonly used for is operations like "Read a record, use columns 50 thru 59 to add to a total, repeat until EOF. Then print the total formatted as $**9,999.99" So the faster you can read records in, the better.
Channels also did buffering when reading from devices like tape drives that did not like to start/stop their motion a lot. So the channel controller would tell the tape drive to read "a few" records and hold them for when the CPU asked for them. Mechanically, the tape reel would slow to a stop and a vacuum column would hold excess tape. The inertia of the reel did not allow for sudden starts/stops and if you tried you'd snap the tape. Curious Marc has a video:
Thanks for the link. This is great. Cheers.
Early disk IO held the channel until the desired record came under the head. That was after the arm was positioned. 370 brought in rotational position sensing allowing other disk IO to take place.
Later on, tapes also accommodated record positioning. Forward Space File came with 360.
Remember though that these days tapes are often archived in a virtual tape library physically on disk, but processed with tape channel commands.
Back in 360,control units that could handle simultaneous IOs appeared. They were connected to two channels.
Was it sufficient to cover all the instructions? The floating point portion seems like a likely risk.
(Perhaps, more likely, the microcode drafts were co-written with hardware designs so they had less risk of a failure.)
Say the instruction is a string copy. The instruction itself might cross a page boundary, and the source might cross a page boundary (perhaps more than one), and the destination can also cross a page boundary. The microcode can't just begin processing the instruction, then hit a page fault, fix up the page mapping, and continue. Instead it must check that each possible read or write will not cause a page fault and only then proceed with the entire sequence.
Cortex M also exposes how far you are into a ldm/stm for recoverable exceptions as well.
I have found this to be a great rule of thumb in software too. Engineers often first instinct is to add "advanced mode", "legacy mode" or whatever. Often with no idea how much trouble having two modes of behaviour will cause downstream in training, understanding, compatibility etc.
The cool kids went to London, Tokyo and Poughkeepsie for training courses - the rest of us toughed it out fixing these venerable old beasts using oscilloscopes and mountains of manuals.
There were no decent helicopter level documentation like Ken's available. Having access to articles like this back then would have been life changing.
I grew up around the city on that list that ain’t like the others. The idea that “cool kids” would be sent there, on _purpose_, and as some kind of _reward__, just made me laugh and laugh even though i know why it’s true and that it’s not a joke.
Actually this looks very, very cool to me. It resembles taming mythological beasts . I wish I had the chance to work on such projects.
There was huge pressure to get the machine back up again. An outage might mean that an entire bank branch was down, or that payroll could not be run. The CEO could be looking over your shoulder. That kind of pressure saps the fun quickly.
Also the bugs could be very, very hard hard to find. In room-sized machines like 3033 for example, there are many thousands of signal leads (trileads) that were many yards long. A slightly bad connection could cause electrical ringing and highly intermittent errors that were excruciatingly difficult to reproduce, let alone to find and fix.
Intermittent errors were common and brutal. You could think you'd fixed it, only to have another crash a few hours later. A common debugging technique was to swap cards around and see if the bug moved. Just doing that often introduced new bugs.
In latter years the role of the on-site engineer was reduced, and often you would be a lacky for some remote engineer back in the plant where the machine was built.
$5 billion in 2022 dollars or 1960s dollars?
Considering that the entire revenue for IBM in 1964 was $3.2 billion (1964 money), spending $5 billion on a project (over several years) was certainly a "bet the company" move.
I should know. Law enforcement were trying to indict me for $100Tn in currency fraud. I wanted to point out to them that this was higher than the GDP of Planet Earth, but I don't think they would have understood what GDP is.
They finally decided not to follow-through on the prosecution for it. I guess someone eventually realized that:
a) It was a real bank note, not a forgery
b) It wasn't US currency as they had believed, but a note from Zimbabwe:
https://www.banknoteworld.com/zimbabwe-currency/100-trillion...
I'm struggling to imagine multiple professional law enforcement staff closely examining it and not noticing that it makes no claims to be US currency.
From this article, which describes the development of S/360 in detail: https://spectrum.ieee.org/building-the-system360-mainframe-n...
While each model of 360 was standardized, customers could request certain options for their machine and IBM would accommodate them. So the testing computer would have to know what the customer's configuration was to know what the wiring was supposed to be for that particular cabinet.
I'm pretty sure that horizontal microcoding is more common, at least in modern CPU design. On x86, the micro-ops are generally wider than the machine code instructions.
Horizontal microcode is much simpler for in-order processors, but my understanding of this stuff seems like they wouldn't work well with the superscalar processors of today. Gating the hundreds of control lines seems (to me) like more effort than gating a few dozen bits of a uop.
Wish I had the time to implement it. OTOH, I'm glad I never had to debug all the analog glitches and timing bugs that design certainly would show when it colided with reality
The bit width is more a heuristic. With horizontal microcode you can look at each group of bits and it's clear 'these three bits are the selection input to this mux', 'this bit is an enable for the buffer linking these two buses', etc. Vertical microcode in contrast is further decoded with bit fields having different meanings based on opcode style fields. RISC in a lot of ways was the realization 'hey, we can assume with this new arch that there's an i-cache, so why have microcode at all, but instead load what was vertical microcode from RAM dynamically and execute it directly'.
Pretty universally, OoO superscalar cores will use vertical microcode (or vertical microcode looking micro-ops even if they don't originate from microcode) because that's the right abstraction you want at the most expensive part of the design: the tracking of in flight and undispatched operations in the reorder buffer, and how the results route in the bypass network. Any additional wodtch there really starts to hit your power budget, and it's the wrong level for horizontal microcode because the execution units will make different choices on even how many control signals they want.
I recall there was a middle layer of microcode such that the computer could run whichever instruction set you wanted.
IBM smothered the lawsuit by buying Platform Solutions and persuaded various antitrust authorities to look the other way.
https://applecon.com/case-studies/ibm-v-platform-solutions-a...
Up to that point many ISVs were using mainframe emulators such as the Flex system, but that license was killed off and ISVs were either pushed to remoting to a mainframe or going to z/PDT.
>"As you can see, the CPU performs many activities in parallel for one microinstruction, which increases the computer's performance."
Would this microcode also be considered one of the first forms of ILP(instruction level parallelism) then?
The System/360 Model 91, a more advanced model, used instruction level parallelism for higher perormance.
For anyone who is curious, the 360 Principles of Operation are at bitsavers: http://bitsavers.org/pdf/ibm/360/princOps/