IBM PC 8088 replaced with a Motorola 68000
microcorelabs.wordpress.com
microcorelabs.wordpress.com
If I remember correctly, the Intel had lots of 8088s available immediately (so IBM could do things like lifecycle testing), and Motorola did not have enough 68000s available yet. IBM was concerned about how much memory you would be able to use with future iterations of the 99000.
The 68000 series did see use in the Macintosh, Amiga, Sharp X68000, and it completely dominated the Unix workstation space in the late 1980s. There were a lot of companies who thought, “I’ll buy a Unix license, buy some M68000s, and sell workstations.” Most of these companies disappeared. Later Unix workstations used all sorts of architectures.
I think the MMU was introduced with the 68020, which then appeared in early Sun 3s, and HP9000s, prior to the RISC invasion. Those machines seemed super fast at the time.
Forking CP/M (cuz let's admit that's basically what PC-DOS was) and offering something similar-but-different to those systems was low-risk. And their original intent in fact was to in fact sell a full-on CP/M machine.
FWIW the Atari ST is what you get when you take a CP/M/PC-DOS-style OS and bolt it onto the 68k. Syscalls were basically 1:1 with MS-DOS, and even used an MS-DOS compatible filesystem. But big-endian. If you want to see what an IBM PC built around the 68k would have looked like, that's not far off.
It would be interesting to port TOS (or more likely EmuTOS) to this 68k IBM PC and kind of go full circle.
(I always assumed it's 16 bit internally as well? Longword unary register operations take slightly longer than their word equivalents, even though the instruction is the same size in both cases.)
Correct, it's mostly 16-bit internally. Registers are 32-bit, but are split into 16-bit halves. The ALU is mostly 16-bit, but has a 32-bit shift register which is used for both shift/rotate operations and multiply/divide. There's a 32-bit adder in the "address unit" that's used for effective address calculations (including the LEA instruction), but it's much more limited than the ALU
> I think the MMU was introduced with the 68020
From: https://news.ycombinator.com/item?id=34762508
"The Sun-1 workstation used a Motorola 68000 CPU at 10MHz. This was paired with an in-house designed MMU. It had 256K zero wait state memory with parity, and 32K EPROM memory."The Sun-1 MMU was segment and page registers indexed hierarchically off the physical addresses.
It was a full page based system with segment and page level sharing and protection.
The 68000 didn't support restart from page faults, so the runtime model was indeed segment level swapping. (Note - not what Linux decided to call swapping)
Most of these early m68k UNIX boxes used the 68010 for that reason.
Besides the tight loop optimization, the other 68010 changes, like move from SR being privileged (new from CCP unprivileged) are bugfixes.
I have seen 68000's and 68020's in everything from musical instruments to electronic measurement equipment to office equipment and networking hardware made into the late 90's at least. The Coldfire series has probably been all but killed off by small ARM chips for complete new product families now, but I'm almost certain you'd be able to find several of them if you went to your local appliance/electronics store today and started taking stuff apart.
While the M68K had its own growing pains (as seen with the evolution of the Macintosh), none of them seemed nearly as onerous as what was done to squeeze a few more years out of MS-DOS compatibility.
I guess in a way the complexity of the PC has more to do with the wide range of platforms, software stacks, etc that were being supported more than the architecture itself.
And frankly despite people wanting to rewrite history there was never a time when the 68000 was clearly a better processor. Yes years like 1985 when the amiga was released machines it showed up in looked light years ahead, but software compatibility/optimization/etc meant that within a year or so the PC was either on top or close to it again. It wasn't really until the early RISC machines started showing up that the PC was solidly eclipsed for more than a couple years straight.
And many of the technical things people complained about (segmentation, few registers) either were partially false by the time they were complaining about them (ex the 386 provided flat 32-bit addressing in 1985, and even windows/386 was only a year and a half later) or net really a consideration. Ex: pascal/c compilers hid register pressure and caches sped up stack spilling/etc.
I was amazed to see Domain OS SR9 running on 20 MHz 68020 CPU with 4 MB of RAM a multiuser, multitasking, (GUI), network distributted OS with diskless clients and file versioning.
This said, several hardware PC-emulators on the Atari did exactly the thing that article describes. PC-Speed added a NEC V30 that was soldered on the 68000 and could takeover the bus and the emulation only consisted on simulating the peripherals. It worked like a charm and thanks to the generous memory of the ST could even do some things better than real PC's (for example the 640K limit was in reality a 736K limit). Later versions used 286 and even 386sx cpu's.
Though as sibling comment correctly points out (and he'd know more than most, BTW) GEMDOS is more a CP/M-alike than a CP/M itself. There's really no or very little code shared in common with CP/M68k (both are under GPL now so you can go and look). I think the only thing shared between the two is the program loader source, and I might even be wrong about that.
But yes I feel like this machine in this article should boot to a COMMAND.COM running on GEMDOS. Or at least CP/M68k. The source is available to make that happen fairly easily.
Not as nice as a PDP-11 processor, but damned close!
I also wouldn't hold my breath while waiting for the 68000 to do anything... all the instructions are enormous, and they take ages to execute.
Edit: well, 24-bit physically, but flat linear address space and an instruction set that permitted 32-bit addressing.
There are many computational instructions that don't make much sense on addresses, especially if you have rich address modes to begin with. And if you'd need to, there was the "movea" instruction for copying between the register files.
You could, in one single instruction,
struct B {
int x, y, z;
};
struct A {
int a, b, c;
struct B *ptr;
};
void func(struct A *array, int i) {
array[i].ptr->z = 3;
}
This is a little closer: https://godbolt.org/z/5K4MEYe31
and IIRC there was also the "LEA" instruction ("Load Effective Address") which stored the computed memory address instead of fetching/storing to that address. And I believe some compilers would (ab)use that to do math as well (though this was complicated by the aX/dX register split)
EDIT: Yeah, so if I'm not misreading MC68020UM the memory indirect mode is slower
move.l #3,([6,a0,d0.l*8],4) ; 9 cycles best case
move.l 6(a0,d0.l*8),a0 ;4
move.l #3,4(a0) ; 3Unfortunately Apple crippled the memory bus on most of its products so as not to compete with its more expensive models like the Mac IIfx. So by the time the 486 DX4 came out, there was simply nothing comparable on the Mac side, and then the Pentium was the final nail in the coffin and Apple had to transition to PowerPC. But modern processors are so microcode-heavy, with advanced pipelining, branch prediction and instruction interleaving, that they can't be programmed by humans anymore, at least not anywhere near the level of optimizing compilers. GPUs also killed the golden age of innermost loop optimization in the late 1990s.
If I could have one wish, it would be to revert all processor "progress" since the 68040 or possibly PowerPC 601 around 1995, and make something like RISC-V with under 1 million transistors, little or no cache, and 68k assembly or simpler. Then arrange them on a 2D grid. The 50 billion transistors of an Nvidia RTX 4080 would make for 50,000 cores, and even if we lose 1-2 orders of magnitude for interconnect, that's still 500 cores. I'd put at least a 16 GB memory directly above that, connected by vias, with a content-addressable caching scheme for in-memory processing. A scalable chip like that would give us 3 orders of magnitude more performance than we have today, and pull away at perhaps 100x improvement each decade. Maybe Apple's M1 will eventually do that stuff, but right now it's too mired in domain-specific hardware for video and AI. I view that with the same skepticism as DSLs and mourn the loss of symmetric multiprocessing. But I digress!
I agree we shouldn't have completely abandoned these machines in the 90s. the massive resurgence we see of vector and simd today proves that there was substantial value - and maybe the software story would be a lot better if we hadn't have taken a 20 year piss break.
Though of course I know it's been done and either failed technically, or failed in the market, several times. E.g. fairly recently the Parallela Epiphany stuff (https://parallella.org/2016/10/05/epiphany-v-a-1024-core-64-...) which sounded super-gee-whiz-bang-neat but went nowhere.
But maybe the application domains and compilers just weren't there for it yet.
I like what e.g. Parallax has done with their Propeller 2, in the microcontroller domain. 8 cores round-robining on a shared memory, but with their own smaller localized workspace RAM, and a pile of I/O. No need for interrupts to manage concurrency, just assign a core to it. https://www.parallax.com/propeller-2/
The complexity is sadly mostly inherent in the problems being solved.
Intel did try to do RISC unsuccessfully with the i860--which also had some sort of VLIW mode, which makes their later Itanium even harder to understand.
Intel was making enough coin from x86 that they were reluctant to EOL it in favour of something RISC. Not that they didn't try. Multiple times (Itanium being the worst, though much later). But each time their replacement failed to ignite, and Intel pulled back from the brink and they pushed something that was a noticeable incremental improvement while keeping backward compatibility.
And with the Pentium & the ISAs that followed they just seemed to pull a rabbit from a hat. They made the x86 CISC architecture scale in a way that pundits at least? didn't seem to think was possible.
Motorola didn't invest in time in doing for 68k what Intel did for x86 with the Pentium. And they screwed over their customers as a result. They basically told everyone (Apple, NeXT, various workstation makers, etc.) to go to 88k. 88k was an architectural failure. So then they did PowerPC along with IBM and others. And people who used 68k previously either went PowerPC (Apple) or rolled their own RISC (Sun with SPARC, HP with PA-RISC, etc.) or just left the market entirely (Apple, Commodore).
ColdFire is roughly to the 68k what Pentium II or so was to the x86 line. It's actually quite nice. They dropped a couple things from 68k but it's about 90% compatible, and can do a very effective software emulation to make itself 100%. But it got pushed basically only as a microcontroller or specialist (routers, ethernet switches, etc.) architecture. You can still buy them from NXP I believe.
These days I don't like big-endian. And the separate address vs data registers seems weird now. But the 68k instruction set was overally very nice. I do imagine sometimes an alternate timeline where Motorola had rolled ColdFire out sooner as an MPU line for consumer stuff and Apple, etc. had used that instead of going PowerPC. I wonder what a 64-bit 68k would have looked like.
IMHO Apple wasted a whole pile of engineering years getting MacOS classic to port over natively to PowerPC. It was extremely unstable and large parts were emulated 68k code for years. It might have saved them some unprofitable years, who knows? They seem to have finally learned the lesson and they own their own CPU now.
The Pentium was not great, not terrible. IIRC 2 ways superscalar in-order, quite faster than the 486 (also because of caches, better memory, faster and wider FSB, way better latencies for tons of instructions) but it would not have been enough if Intel had tried to just make it evolve slowly.
Of course at the time and taking price and competition into account, it was quite good to make faster PCs. But by itself it only showed a limited capability for scaling x86.
The Pentium Pro was the uarch that showed that scaling was possible. Even if they have been deeply refined across the years and generations (putting NetBurst appart, of course), most of the technics it introduced in the x86 world are still a foundation of how the current generation x86 cores work. The rabbit that came out of the hat was the result of quite a number of years of work, most of it parallel to the P5 dev. The Pentium II consolidated that with better support for consumer software of the time (with still copious amount of 16-bit code), and, logically, marketing for consumer hardware (with manufacturing progress and tricks allowing a price not too high).
Eh, I don't agree. Look at the other superscalar microprocessors available around the same time:
* POWER (1990)
* Alpha 21064 (1992)
* PA-RISC 7100 (1992)
* Pentium (1993)
* POWER2 (1993)
* MIPS R8000 (1994)
* PA-RISC 7200 (1995)
* UltraSparc (1995)
* Alpha 21164 (1995)
So, first of all, all of these are in-order processors. Out of order execution didn't come until later ('95 for PA-8000, '96 for R10k and Pentium Pro and '98 for Alpha 21264 and Power3).
Second, all of the RISC superscalar processors prior to the Pentium are also (technically) dual issue.
But Pentium did something unique: It can issue two integer instructions in the same cycle. Before that, all the others could issue only one instruction of a given type (load/store, int, and fp) per cycle. In other words, while they may be "dual issue", your instruction stream needs a mix of those types to get any benefit from multi-issue on those early implementations.
In terms of having 2x execution units of the same type: POWER2 got there later in 1993, but was not a single-chip processor, followed by R8000 (also multi-chip), PA-7200 and 21164.
That's why Pentium had pretty good integer benchmarks, even while it was getting crushed on floating point compared to RISC.
Worth noting that had Commodore's astonishingly out of touch and schizophrenic corporate management not driven the company into the grave, the Amiga engineering team had already settled on PA-RISC as their next generation architecture as well, and I believe even had reached prototype stage on the vapors of cash renained in their final months of existence.
The 90s was the era of Dell JIT delivery and grey-box clones. The margins fell out of the whole market. There was no room for the likes of an Atari or Commodore.
Apple only turned things around for themselves in the next millennium by becoming a luxury brand maker of consumer appliances, and "computers" as we know them have become a much smaller market than handheld devices.
Maybe the "Amiga" brand could have continued as a high end graphics card line for PCs. (But it's not like there was any special sauce left in Commodore eng talent that could have made anything competitive). But Commodore as a maker of home computers or workstations? Nothing could have saved them.
Sometimes I wonder if there was a point in time - where real history switches to a fantasy history - in which a non-pc clone paradigm ends up winning that war. If so what was the earliest point this could have happened, and would it even matter since market forces would ultimately pull any alternate success in the direction of an informally standards-federated clone paradigm anyway.
It seems as if VLIW with a sufficiently smart compiler to handle the instruction packing was the "fetch" Intel kept trying to make happen, but it wasn't going to happen (people kept stumbling on the "sufficiently smart compiler" bit). First with the iAPX 432, then the i860, then Itanium.
I'm talking products like QEMM, Sidekick (and the whole "terminate and stay resident" industry), expanded vs. extended memory, and other massive engineering efforts by major software (Lotus, Ventura Publisher, etc.). Time spent overcoming the limitations of the 640K barrier, segmented memory, and similar design challenges could have been spent in more productive ways, as could be seen in the development of other ecosystems on a comparative shoestring budget.
Granted I was an Amiga aficionado back in the late '80s/early 90's, so I'm comparing things like the ATI VGA Wonder (1988) to the Video Toaster (1990), or early efforts at GUIs (like GEM) to the multitasking OS of Amiga. But still, I think the point stands.
The late 70s / early 80s incarnation of Microsoft was happy to port their software to just about anything, so long as there was a customer willing to pay for it. If IBM had asked Microsoft for a 68K OS instead of an x86 one, Bill Gates would have found a way to provide. He bought PC/MS-DOS from another company, he probably could have found someone selling a 68K OS instead. Or Tim Paterson surely could have ported it to 68K if asked.
I think choosing the 8088 over 68K was all about hardware costs, not software-both the cost of the CPU, and the cost of compatible peripheral chips.
Maybe even demand some optional record-oriented support in the filesystem (e.g RECFM=F80). That would have been less alien to Microsoft than you’d think, because Microsoft BASIC always supported record-based file access.
particularly this, i think, and also availability.
https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compati...
A detailed description (with pictures) can be seen on page 278 and following ones of BYTE Magazine, February 1984 issue. The computer was branded as "IBM Instruments"
https://archive.org/details/byte-magazine-1984-02/mode/2up?v...
The first answer on this forum post has what is probably the correct explanation for why the 8088 was chosen:
It was available, had a second source, and was not owned by a competitor.
https://retrocomputing.stackexchange.com/questions/16912/did...
Although ease-of-translation from 8080-based CP/M code was a benefit of choosing the 8086, this was just a nice-to-have, not a deciding factor.
Here an (emulated) MC68000 is pressed into serving an 8bit bus.
The 68k (using its native 16bit bus) is faster (even if not by much) than a 8086.
That would be a big thing. 8088 assembly language is source-code compatible with 8080 assembly language. I believe IBM was eyeing the ability to run CP/M and derivatives like CP/M-86. IBM/MS DOS is basically a CP/M-like, derived from this:
https://en.wikipedia.org/wiki/86-DOS
"[86-DOS's] application programming interface was very similar to that of CP/M. The system was licensed and then purchased by Microsoft and developed further as MS-DOS and PC DOS."
[1] https://web.archive.org/web/20010823113747/https://www.pcmag...
This was a simple and fun read while waiting for my coffee to be done. I also wonder how the world would look if IBM partnered with Apple rather than Microsoft.
Possibly underwhelming, if Taligent was any indication.