6 ms·
I think the 80386's final design benefitted tremendously from the Motorola 68000, then the m68020. Had Motorola not released a proper 32 bit CPU without comprom
by johnklos 3y ago
I think the 80386's final design benefitted tremendously from the Motorola 68000, then the m68020. Had Motorola not released a proper 32 bit CPU without compromises, it could be argued that Intel would've had yet another stop-gap after the 80286, which itself wasn't intended to be a proper successor to the 8086/8088.
As it is, the 80386 came with a number of compromises. For instance, there was no cache at all beyond a 16 byte instruction prefetch queue, whereas the m68020 had 256 bytes of instruction cache. There were no atomic instructions (LOCK wasn't useful for this), which is why many modern OSes support the 80486 but not the 80386. The fact that compatibility with the 8086 required real mode or VM86 meant that it took quite a long time before software started taking advantage of the 80386's new features.
It was an important chip, but it showed us early signs of what we've come to expect from Intel: attempts to create other markets at the expense of, or with the express desire to not compete with, the x86 (the iAPX 432 then, the Itanic twenty years later), the slapdash addition of "features", such as the additions to the 80286, which then were required to be included forevermore as legacy support, the rushing-to-catch-up when other vendors had features that everyone wanted (real, flat 32 bit support then, 64 bit support twenty years later).
Still, it's interesting history!
- flashback2199 3y agoIt was a 386 that Linus Torvalds wrote the first Linux kernel on, and support for the new features of the 386 from the start was one of the reasons Linux took off instantly.
- sertsa 3y agoIndeed! My first taste of Linux was Slackware on a 386
- flashback2199 3y agoMore info: "It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386" https://www.cs.cmu.edu/~awb/linux.history.html https://www.cs.cmu.edu/~awb/linux.history.html
- monocasa 3y agoWhich is probably one reason why he worked at Transmeta for a while.
- fennecfoxy 3y agoI'm sorry, but I had to. "Could someone please try to finger me from overseas".
- rob74 3y agoYeah, a free (as in freedom, but also as in beer) OS running on hardware that was, by then, commoditized, what's there not to like? No wonder Google and others jumped on it...
- steve1977 3y agoNot only Linux, all the current BSDs share a lot of “DNA” with 386BSD.
- zozbot234 3y ago> There were no atomic instructions (/LOCK wasn't useful for this), which is why many modern OSes support the 80486 but not the 80386. Does the lack of atomics really matter, given that there was (AIUI) no SMP on the 386? You can always disable interrupts to make your operation 'atomic' in a uniprocessor context.
- jacquesm 3y agoDisabling interrupts is a privileged operation (you need IOPL for the ability to execute the cli or sti instructions). Atomics can work even outside of privileged code. Otherwise you could from any user program disable interrupts and give the operating system no chance to take back control. Xadd, cmpxchg, bts, btr and btc are all prefixable with lock to make them atomic.
- jhoechtl 3y agocli jmp far $-4
- adrian_b 3y agoAlready starting with 8086 all Intel x86 CPUs have been intended to be usable in SMP systems. Nevertheless, there have been very few SMP systems using early Intel CPUs, before 80486, mainly because those CPUs were still too weak in comparison with the contemporaneous mini-computers, and not even SMP would have made them competitive in performance, while the high price of SMP would have been incompatible with personal computers. Intel 80486 has been much more frequently used in SMP systems, not only because it had added the more convenient atomic fetch-and-add and compare-and-swap instructions, but because Intel had also provided for 80486 an APIC integrated circuit, i.e. a multi-processor interrupt controller, and also because 80486 was very fast and a SMP system using it was competitive with much more expensive computers. Intel 8086 was intended to be used in SMP systems by using the atomic swap instruction proposed by Dijkstra, i.e. LOCK XCHG with the Intel mnemonics. The atomic swap is good enough to implement any kind of concurrent programs, albeit at a lower performance and higher complexity than when the atomic instructions added by 80486 (LOCK XADD and LOCK CMPXCHG) and Pentium (LOCK CMPXCHG8B) are available. The 80386 has added atomic fetch-and-modify-bit instructions, which remain useful even today in wait-for-multiple-event scenarios (together with LZCNT, which can be used to get the highest-priority event that must be serviced).