Prior to POWER on the RS/6000, AIX ran on the IBM PC RT:
https://en.m.wikipedia.org/wiki/IBM_RT_PC
This ran on the ROMP processor:
https://en.m.wikipedia.org/wiki/IBM_ROMP
This system was a bit before my time.
https://en.m.wikipedia.org/wiki/IBM_RT_PC
This ran on the ROMP processor:
https://en.m.wikipedia.org/wiki/IBM_ROMP
This system was a bit before my time.
VRM was written, not in C, but in a PL/I dialect (not sure which, but probably PL.8). So AIX for RT PC is a rare example of a Unix whose kernel is (partially) written in a language other than C. The only other example of that I know of is IBM z/OS (which most people don’t think of as a Unix, but officially it is one, since it passes the certification test suite and IBM pays The Open Group the Unix trademark license fees.)
I say partially because the actual AIX kernel is in C, but it then calls to the VRM microkernel which isn’t in C. But a lot of basic functions which normally belong in a Unix kernel are in the VRM instead and the AIX kernel is just a thin wrapper over them.
When AIX moved to the RS/6000, the VRM microkernel was dropped, and AIX from then onwards was a classic monolithic kernel all in C.
Well, historically “AIX” has been a brand for (many but not all) IBM Unixes, with several unrelated code bases being labelled “AIX”. One of those, AIX/ESA (for IBM mainframes), was actually based on OSF/1, and hence used the Mach microkernel. But it was discontinued in the first half of the 1990s, when MVS gained Unix compatibility support. And all the other “weird” AIX variants are also now long dead, so in practice AIX for RS/6000’s descendant is the only AIX left.
AIX is a bit like DB2, in that both were brand names for multiple distinct code bases. The difference is all but one AIX code base died, whereas multiple DB2-branded code bases are actively supported today.
How much use all these different ports saw, I don’t know. Obviously some of them were pretty big (you mention Prime, I’ll mention R83) - others less so. I wonder how many customers IBM RT PC PICK ever actually had. Probably significantly less than PICK ever had on AIX for RS/6000 (at one point several different PICK vendors offered Unix ports, and AIX was commonly on the list of supported Unix flavours)
I hate it.
According to Wikipedia:
Approximately 23,000 RTs were sold over its lifetime, with some 4,000 going into IBM's development and sales organizations. Pick OS sales accounted for about 4,000 units.
I do remember the Pick greybeards being dismissive of this new fangled SQL stuff: "we had relational databases before SQL don't you know"
[0] https://ardent-tool.com/615x/The_Virtual_Resource_Manager.pd...
One ran on top of Sperry/Univac OS2200 EXEC-8 (and this was the first SMP UNIX AFAIK):
https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf
"The UNIX system for the UNIVAC 1100 series was built as an integrated development environment for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain services that would normally be provided by device drivers, and some process creation and management services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system."
A Bell Labs port to an IBM mainframe ran on top of TSS/370:
https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
"Of the available systems, TSS/370 came the closest to meeting our needs and was thus chosen as the base for our UNIX system implementation. The choice of TSS/370 was a controversial one; it is a little known and inadequately documented system. Still, it came the closest to providing the structure and function needed to support UNIX system processes, and it appeared that it could be enhanced to provide any missing functions with reasonable effort. In 1979 we proposed to IBM that they make the necessary modifications to the TSS supervisor to support UNIX system processes, according to our design. IBM agreed to do so under a program license agreement, and the first version of the enhanced TSS was delivered in 1980."
I can think of another: the University of Wollongong’s port of Unix V6 to the Interdata 7/32 started out running under Interdata’s OS/32, until the port advanced to the point that they could get rid of OS/32 and run it directly on bare metal. I suppose this differs from these other ports in that it was only ever intended as a temporary stopgap while the port could be completed, not as a final destination: http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
The Princeton port that evolved into Amdahl UTS maybe also counts, since early versions could only run under VM, not bare metal. That meant they could use VM’s simplified paravirtual device API (hypercalls via DIAG instruction), that hid some of the complexity of mainframe IO-running on bare metal required dealing with those complexities directly
I actually went over the Univac and TSS ports in my parallel xargs article:
https://www.linuxjournal.com/content/parallel-shells-xargs-u...
In my workplace, we still have fully-supported OS2200 running the DMS hierarchical database.
We are also running VAX VMS on the Charon emulator, but there are plans to replace the VAX's functions with Rockwell's "Factory Talk Production Center."
Also TIL: Eric Schmidt worked on that port apparently ( https://en.wikipedia.org/wiki/Amdahl_UTS ), in addition to or around the same time as his ?summer? internship work at Bell Labs as co-author of Lex (https://en.wikipedia.org/wiki/Eric_Schmidt). That would have been before he went to Berkeley and then joined Sun as its first software manager.
Tom Lyons's 3-part blog post on the port (which he worked on) adds nice context and some fun to read technical tidbits and commentary: https://akapugs.blog/2018/05/12/370unixpart1/
Aparently Eric didn't just work on the port, he recognized the technical pieces were in place enabling a port and organized the collaboration to carry it out. Although in a funny line in that same piece, Tom notes: "Eric, in a display of his future managerial potential, did not participate in the actual technical work, but deserves a lot of credit for working the system to make things possible."
Not mine. First Unix box I ever touched, in my first job, here on the Isle of Man 36Y ago.
It was a demo machine, but my employers, CSL Delta, never sold any AFAIK. It sat there, running but unused, all day every day. Our one had a mono text display on it, and no graphics ability that I know of.
I played around, I wrote "Hello, world!" in C and compiled it and it took me a while to find that the result wasn't called "hello" or "hello.exe" or anything but "a.out".
If I had the knowledge then, I'd have written a Mandelbrot generator or something and had it sit there cranking them out -- but I was not skilled enough. It was not networked to our office network, but it had a synchronous modem allowing it to access some IBM online service which we used to look up tech support info.
Synchronous modem comms, or serial comms, are very different indeed to the familiar Unix asynchronous serial comms used on RS-232 connections for terminals and things. Sync comms are a mainframe thing, more than a microcomputer thing.
https://wiki.radioreference.com/index.php/Asynchronous_vs_Sy...
That modem was a very specialised bit of kit that cost more than a whole PC -- when PCs cost many thousands each -- and it couldn't talk to anything else except remote IBM mainframes, basically.
The RT/PC felt more powerful than a high-end IBM PC compatible of the time, but only marginally. It had a bit of the feeling of Windows NT about 6-7 years later: when you were typing away and you did something demanding, the hard disk cranked up and you could hear, and even feel the vibrations, that the machine was working hard, but it stayed responding to you the same as ever. It's a bit hard to describe because all modern OSes work like this, but it was not normal in the 1980s.
Then, OSes didn't multitask or they did it badly, and things like hard disk controllers of the time took over the CPU completely when reading or writing. So on MS-DOS, or PC-DOS or OS/2 1.x or DR Concurrent DOS, when you typed commands or interacted with programs, the computer responded right away as fast as it could. But if you gave a command that made the machine work hard, like asked for a print preview or a spell-check of a multi-page document, or sorted a spreadsheet of thousands of rows, or asked it to draw a graph from hundreds of points of data, the computer locked up on you. The hard disks span up, you heard the read/write heads chattering away as it worked, but it was no longer listening to you and anything you pressed or typed was lost. Or, worse, buffered, and when it was done, then it tried to do those commands, and quite possibly did something very much not what you wanted, like deleted loads of work.
(Decades later something similar happened with cooling fans, and now that's going away too. But with hearing the fans spin up, there's a hysteresis: it takes time, and tens of billions of CPU cycles, for the CPU to heat up, so the fans come on later, and maybe stay on for a while after it's done. A PC locking up as the hard disk went crazy was immediate.)
The RT/PC was a Unix box. It didn't do that. No idea how much RAM or disk ours had: maybe 4MB if that, perhaps 100-200MB disk. A lot for 1988! But if I did, say,
cd / ls -laR
... then it would sit there for several minutes with the HDD chuntering away, listing files to screen... but what was remarkable was that you could switch to another virtual console and it stayed perfectly responsive as if nothing were happening. That hard disk was SCSI of course, so it didn't use loads of CPU under heavy disk load.
The machine always felt a little slower, a little less responsive than DOS, but it never slowed down even when working hard. You had the feeling of sitting behind the wheel of a Rolls Royce with some massive engine there, but pulling a massive weight, so it didn't accelerate or brake fast, but could just keep accelerating slowly and steadily 'til you ran out of road... and you'd make an impressively large crater.
We sold a lot of IBM PS/2 machines with Xenix, and it was a Unix too and felt the same... but limited by the puny I/O buses of even high-end 1980s IBM PS/2 kit, so it sssslllloooowwwweeeedddd way down doing that big directory listing.
Whereas contemporary PC OSes responded quicker but just locked up when working hard. This included Windows 2, 3.x, 95, 98 and ME, and also OS/2 1.x, 2.x, and Warp. The kernels did not support multithreading and background I/O very well, so it didn't matter that the hardware didn't either.
Then Windows NT 4.0 came along, and it did. Suddenly the hardware mattered. But if you had a Pentium 1 machine, with an Intel Triton chipset on the motherboard, there was an innocent looking driver floppy in the box. On that was a busmastering DMA driver for the Intel PIIX EIDE controller. Install it on Win9x and it could see a CD-ROM on the PATA bus. Handy but not world-shattering.
Install it on an NT machine and once the kernel booted, the sound of the hard disk changed because the kernel was now using busmastering to load stuff from disk into RAM. As the machine booted the mouse pointer kept moving smoothly, with no jerkiness. When the login screen appeared it blinked onto the screen and you could press Ctrl-Alt-Del and start typing and your username appeared slowly but smoothly. The stars representing your password, the same.
It suddenly had that "massive computer power being used to keep the machine responsive" feeling of an RT/PC the decade before. Like that PIIX driver had made the machine's £100 cheapo IDE disk into a £400 SCSI disk.