Intel 80386, a Revolutionary CPU
xtof.info
xtof.info
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!
"It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386"
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.
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.
jmp far $-4
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).
XCHG is enough to implement a mutex though, which is what most applications need.
They are only a performance enhancement and they indeed require either compare-and-swap (simple and double) from the IBM System/370 (1973) (later used by Motorola MC68020, then simple compare-and-swap was added to 486 and double compare-and-swap to Pentium) or load-locked + store-conditional from the S-1 Advanced Architecture Processor (LLNL, 1987) (later used by MIPS, then by POWER, ARM and others).
Moreover, even for improving the performance the lock-free and wait-free algorithms must be used with care, because they are based on optimistic assumptions that may fail to be true in many scenarios with heavily contended shared resources, when the performance of the algorithms based on mutual exclusion is actually higher and more predictable (with mutual exclusion it is easy to guarantee FIFO access to a shared resource, which ensures that the wait times are bounded and that at any moment there is at least one thread that does useful work instead of retrying failed accesses to the shared resource).
In any case this has nothing to do with performance, you might need lock-free algorithms for correctness when implementing some real-time systems or when you need code to be reentrant.
Access to any kind of shared resource is always correct when only a single thread can access it.
With mutual exclusion it is very easy to guarantee correctness due to serialized accesses. With lock-free algorithms concurrent accesses are possible and the algorithms must be carefully analyzed to demonstrate their correctness.
Moreover, exactly in real-time systems is where lock-free algorithms are undesirable. Any pure lock-free algorithm must detect a transaction failure and retry it. There is no guarantee of success and no limit for the number of retries, so any hard real-time deadlines can be missed. Lock-free algorithms can be used in real-time systems only if they detect too many retries and then they fall back to lock-based algorithms before it is too late.
The lock-free algorithms improve only the execution time of the typical case, but they increase the execution time for the worst case. For non-real-time applications the typical performance is more important, so lock-free algorithms are good, but for real-time applications the worst-case performance is the most important, which makes lock-free a.k.a. optimistic algorithms bad.
Also neither mutual exclusion nor lock-free/wait-free algorithms have any problem with reentrancy when implemented correctly. Problems with reentrancy appear only in programs where there are mutable variables that are shared between threads and which should not have been shared (like when using some of the old standard C library functions).
It is very common to have a very large number of threads that use reentrantly the same code that implements mutual exclusion for accessing some shared resource that is guarded by a lock.
For example an interrupt handler (or a signal handler) that needs to modify some shared resource. It can't take a mutex or even a spin lock because it might be owned by the thread it just interrupted. There are ways around that of course, for example by having threads disable interrupts inside critical sections, but that's not always appropriate.
Similarly, for realtime systems, if you have threads with different priorities accessing the same data, to avoid deadlocks you either need mutexes with priority inversion (which has its own share of issues) or you use lock free code.
edit: in any case the point isn't that there are better ways to write a program. The point is that if you have a program that uses a CAS-based lock-free algorithm, porting it to 386 it is not just a matter of paying a performance penality, you might need to rewrite it to preserve correctness.
edit2: > There is no guarantee of success and no limit for the number of retries, so any hard real-time deadlines can be missed. Lock-free algorithms can be used in real-time systems only if they detect too many retries and then they fall back to lock-based algorithms before it is too late
wait-free algos have guaranteed bounds.
Therefore an interrupt handler must always own whatever data structures it writes into, so it may write them at any time.
Lock-free methods are not used inside interrupt handlers, but they are used by the code that reads what the interrupt handlers write. However this is the special case of single writer with one or more readers and this special case of lock-free access does not need compare-and-swap instructions or equivalents.
For some particular cases, like counters that are updated by interrupt handlers, the readers can detect corrupt values and retry the reading, while for other cases, when the interrupt handler updates a more complex data structure, that can be guarded, for example, by a counter that is incremented both before and after the updating, so that the readers may be able to detect when they have to retry the reading.
This special case of lock-free access does not need compare-and-swap, but, depending on the CPU memory access model, it may need store barriers a.k.a. store fences and load barriers a.k.a. load fences. Such lock-free access was trivial to implement on Intel 8086 or even earlier CPUs, because it does not even need atomic read-modify-write instructions.
Normally, when lock-free algorithms are discussed, it is assumed that there are multiple writers, when different algorithms are needed than for the single-writer case, and when CAS instructions or equivalents are needed.
There is no need for lock-free algorithms for avoiding deadlocks. The obvious solution to avoid deadlocks is to use a single lock protecting all shared data. Lock-free algorithms may provide a much better performance, but they are not necessary.
Moreover, even without lock-free methods, deadlocks may be avoided in most cases by reorganizing the shared data. Any program where it is necessary at any point to hold multiple locks, is suspect of having a bad data organization, because this should not normally happen.
You are right that wait-free algorithms by definition have guaranteed bounds, but unfortunately they are seldom applicable, otherwise concurrent programming would have been much easier.
Didn't all XCHG with memory operands have an implicit LOCK prefix on Intel 8086?
On Intel 8086/8088 and 80186/80188 an explicit LOCK prefix is required.
It could have easily gone awry as it did for Data General, Honeywell, CDC, AST, Tandy, Olivetti, Xerox, DEC Rainbow, AT&T Hobbit, Wang 2200 and Unisys. Strong survivorship bias on this one. Most of the once Titans are in or near the dustbin now, such as SDS, SDC and Fairchild.
Intel's history was primarily as a memory manufacturer. They're arguably near a similar fucked position now - effectively 0% of the mobile and home appliance market and getting slaughtered in their only remaining stronghold by NVIDIA, AMD and ARM pillaging their castle. Hopefully they'll squeeze out of this one.
The difficulty is they need to make nearly decade-long bets that are the size of small countries economies due to the complexity of manufacturing and Intel's made a few bad ones recently.
I don't know who to listen to on what chip design will be a market win in 2030 either. AI applications are extremely resource intensive so that will be driving things for a while but how to solve that in an affordable chip created by a reliable efficient manufacturing process is beyond me. This stuff is phenomenally hard.
I'd say the winner is something like an NVIDIA graphics pipeline that is separated into a pile called "graphics" and "ai" and then has the graphics part gutted for a cheaper AI pipeline which can use system memory as opposed to preciously expensive graphics memory and then gets integrated into their next gen CPUs taking Nvidia out of the loop and dealing a blow to AMD at the same time. They'd mop the floors with something like that especially if you could just drop it into pytorch and have it work automagically. They could probably then just turn around and license it to ARM.
AMD and Nvidia wouldn't work together to mount a unified defense because of ATI and this would allow Intel to weasel their way back into the Apple money stream.
But I'm just some unemployed dude typing this on a 4 year old android. Don't listen to me.
They have an NVIDIA mainline competitor in their A770 but I think they should be exiting the direct nvidia assault strategy. I really don't know how that's going to work. They're basically a nonplayer https://www.videocardbenchmark.net/high_end_gpus.html
What's their winning move in that approach? It's just money in a volcano.
This just appears to be the case with everything else. Making a video game, movie, song, computer program, etc, requires more resources than using one and there was a significant price delta between them for a long time.
I do not see it with an ARM mode, because there's no such software moat stuck on that platform as there is with x86.
> "Business success contains the seeds of its own destruction. Success breeds complacency. Complacency breeds failure. Only the paranoid survive."
Something that Intel's leaders didn't pay attention to during the 2010s.
The story is about what if we all go out off this room and come back like a new guy. What would we do?
"strategic inflection point" ...
They decide to move from a memory company to a CPU company.
No access to Nikon but being just a Leica len maker for Canon (and famously found by DDD and used in Korea War), then move to nikon rangefinder (but strangely follow Zeiss approach more). Then jump ship to SLR by inventing Nikon F (and used in Vietnam War). It is just crazy move, but at least it is related. And "survive" and move on.
Or just like Fujifilm move to cosmetic in one stage as making film has some knowledge that can be re-used there. And survive and move on.
While no longer on the cutting edge, they still have a significant presence in the semiconductor lithography business. So they will survive in one way or another even if they stop making cameras one day.
NVIDIA doesn't make good CPUs, even their SoCs are ... not exactly state of the art. No mass market adoption besides automotive who don't care about anything but long availability of (spare) parts and the Nintendo Switch which likely only still uses the same 2015-era Tegra chipset because even someone as big as Nintendo couldn't kick enough arses at NVIDIA to bring up a new design. ARM doesn't make generally available server CPUs (the ones that do exist all get gobbled up by cloud providers), and there are outside of the Mac world no viable ARM desktop or laptop CPUs because Qualcomm completely fucked up that market for likely years to come - I don't see any way of ARM adoption in that market unless ARM comes up with a competing solution to Rosetta and Qualcomm comes out of the mindset "if it works just barely, ship it" that may be acceptable to smartphone vendors but not the PC/desktop market.
That leaves AMD as the sole remaining threat to Intel, and AMD doesn't have the fab space to be enough of a threat to Intel's moat.
Yes, I may or may not be extremely frustrated at the state of competition in general computing.
The Pi 400 isn't their final attempt into the PC market, only their first. Surely a slew of decent ARM based laptops from one of these SBC manufacturers is coming along eventually - and I don't mean chromebooks.
In the Windows world, no one holds even closely to the capabilities required for a transition to ARM: Microsoft doesn't have a fat binary standard or the toolchains needed (that all went down the drain with the end of Microsoft Windows CE / Windows Phone and even then, it was a nightmare to develop for these), the third party developers - especially the enterprise tailor-made application market - have zero experience with ARM and a lot of stuff used in enterprise was made by companies that went defunct long ago, Microsoft doesn't have any hold over what the device vendors do in terms of drivers (unlike Apple, who famously cut ties with NVIDIA because NV didn't want Apple to write drivers for their GPUs), and neither Microsoft itself nor the conglomerate of hardware OEMs has the cash in hand to take all the stuff people use on x86 Windows and make it work on ARM Windows (as they infamously discovered with the early Windows Qualcomm stuff). Oh, and the ARM vendors can't be bothered to get something as basic as PCIe working on a fundamental level beyond "if it works in my very specific use case, ship it" - just look at the RPi 4's issues where people developed breakout boards for PCIe only to discover that crucial functionality was flat out broken [1]. And even with people complaining for years about PCIe issues on the Pi 4, turns out the Pi 5 still managed to fuck things up [2].
The only player in town able to make ARM work on anything but smartphones and servers is Apple, and they don't (and never will, assuming regulators don't finally wake up and force them) sell to third parties.
> The Pi 400 isn't their final attempt into the PC market, only their first. Surely a slew of decent ARM based laptops from one of these SBC manufacturers is coming along eventually - and I don't mean chromebooks.
These things are and will be toys. The money is in getting corporate to switch over to ARM and until the problems above (especially backwards compatibility and standards conformance) are worked out, which I don't see happen any time soon because it's so hard to break through the chicken-egg scenario, there will be no threat to Intel. Especially not if even many years of development and complaining are not enough to arse Broadcom into fixing PCIe.
[1] https://www.jeffgeerling.com/blog/2023/i-built-special-pcie-...
[2] https://www.jeffgeerling.com/blog/2023/testing-pcie-on-raspb...
Windows NT shipped on about 7 or so architectures including PowerPC for the Xbox360. And they also have experience with emulation, that's how they got Xbox 360 emulation on the newer X86 models. Just read their papers on arch emulation.
What they don't have and Apple has is 10+ experience in shipping tailor made ARM chips fit to their needs, because they always left chip design to their partners, as they were always a SW company first not a HW product company like Apple, and this isn't something they can start and catch up with in the snap of a finger.
The entire NT stuff has gone down the drain. The last non-x86 platforms were dropped around 2000 [1] until ARM entered the picture in 2012, but the latter was mostly used for Windows Phone for many years which itself got discontinued around 2017.
All these many thousand human-years of experience have long ago retired or went to other companies, their institutional knowledge is effectively lost for Microsoft. And that is the problem.
[1] https://en.wikipedia.org/wiki/Windows_NT#Supported_platforms
Somehow there is a certain irony on that.
Apple has more leverage over devs; they can say "No more x86-64 in N years" and the developers basically have to move to ARM or abandon MacOS. This bootstraps the market; people who want MacOS have to suck it in and buy ARM because it's the only new hardware we'll be seeing in the future.
Microsoft doesn't control the hardware sector to put a hard deadline on new x86-64 products, and it would be suicidal to cut off the x86-64 software support at any time in the near future.
This means we'll see new x86-64 Windows machines in the store, and all the third-party apps supporting x86-64 Windows, for years to come. So as a consumer, why would I want an ARM-Windows machine? It has little exclusive software, is likely buggier and less mature, and probably runs the vast majority of x86-64 software in an emulation penalty box.
arm cpu performance advantages at low power are great. i'm typing this on an m2.
but i'm sure intel will figure out how to have great cpu's at low power draws that perform well. amd already did. so i'm sure intel will.
I think Microsoft could do the same thing as far as devs go. If Apple can exert that influence over devs with their extreme minority market share, I think MS could too. The problem for MS is their customers. Apple customers will buy whatever Apple puts out, because they're extremely loyal to the brand. The same isn't true for Microsoft, and I imagine that pressure would cause them to fold on any major changes.
That's absolutely unrealistic. The main Windows part is the backward compatibility + the corporates. Nowadays Microsoft develops stuff written in Javascript, not their own frameworks, even.
I was one of the early adopters of Windows on ARM, the Windows 10 native port to ARM64 (ARMv8). At release, practically the only native development tool was WinDbg -- neither Visual Studio nor Windows Performance Analyzer had been ported. You could install Visual Studio in x86 emulation mode but it wouldn't run reliably as the toolchain would keep throwing heap errors, so cross-compilation was required and debugging was harder. There was basically zero information about what was and wasn't supported -- you'd just start porting and run into something like there being no OpenGL acceleration support. Or even more fun, that there was no ARM64 version of the Visual C++ Redistributable published, so you couldn't distribute a program that was dynamically linked to the CRT -- and the Visual Studio support staff didn't even know what ARM64 was and pointed to the x64 redist. This didn't start getting ironed out until around three months after Windows on ARM machines had started shipping.
And assuming you got past these problems, Windows has no universal binary system, so it's your job to figure out how to properly get the right platform executable installed and launched without any support from the OS. This was really bad in the early days of x64, where XP would just say "invalid executable" when trying to launch a x64 program on x86; these days it displays a slightly less cryptic "Machine Type Mismatch" error dialog with no further help.
Microsoft is trying to fix these problems now, but they're years late and the amount of software available as native ARM64 is still very low. Oh, and they already dropped support for the early gen Snapdragon 835 and 850 devices in Windows 11, which means no x64 emulation or ARM64EC support, and an even tinier effective market. In contrast, Apple managed the ARM transition much, much better -- they had native tooling, documentation, and development systems lined up in advance and a much more polished user experience on day one.
Traditionally Microsoft isn't like the others (Apple/Google), "take this or go away", which is why they became so big for enterprises in first place.
Heh, https://cdixon.org/2010/01/03/the-next-big-thing-will-start-...
«The reason big new things sneak by incumbents is that the next big thing always starts out being dismissed as a “toy.” This is one of the main insights of Clay Christensen’s “disruptive technology” theory.»
Tho Raspberry Pi computers are designed to a low price point, so they are aiming for the low end not the high end. But the 5 is about as powerful as the last-generation Intel MacBooks, despite using fairly old Arm cores. I don’t think they can be casually dismissed.
https://learn.microsoft.com/en-us/windows/arm/arm64ec
Besides Windows NT has been designed and used for multiple architectures for years, Windows CE and Pocket PC were not the only ones with ARM support, Windows IoT and the original Windows 8 WinRT tablets did as well.
The biggest issue is lack of incentives, for most business there is no ROI to install ARM compilers alongside x64 for .NET and C++ toolchains, and yet another set of architectures to debug on, and take into consideration.
It is as you say, unless they behave like Apple or Google, imposing a transition, most of those companies won't care.
They have recently putted out a kind of ARM porting help center, but I doubt it will make any impact.
https://blogs.windows.com/windowsdeveloper/2023/10/16/window...
I think that would be new territory for regulators. Have there ever been examples where they forced a vertical integrator to sell individual parts to other parties (either at mass to other manufacturers or to consumers?)
You're thinking about lack of support for NVidia eGPUs but the bad blood goes back to 2008 when NVidia screwed apple with failing GPUs in macbook pros and told Apple to pound sand.
https://hothardware.com/news/apple-admits-nvidia-gpu-defect-...
Huh citation needed? I would like to know more context on that
[1] https://www.xda-developers.com/qualcomm-exclusivity-deal-mic...
[2] https://www.digitaltrends.com/computing/why-windows-on-arm-c...
not a huge fan of Qualcomm but you might be interested in this:
"Qualcomm Snapdragon X Elite Performance Preview: A First Look at What’s to Come" https://www.anandtech.com/show/21112/qualcomm-snapdragon-x-e...
The state of Qualcomm products over the last years has left me with absolutely zero confidence.
DEC should have packaged the LSI-11 into a consumer machine. They had all the software, which was top shelf.
I had an H-11, it was a great machine.
I wonder how early one could capture the complexity of the full PDP-11 microarchitecture on a single chip? Would it have been affordable? What about the support hardware?
Linux kernel has memory barriers, Alpha makes an exception with needing virtually all of them - with other architectures (esp. the total store order ones) some (most) of the barriers are nop.
Yet, overall Alpha is famous for how crazy the memory model is. There is nothing like any longer (personally I am happy with Java Memory Model). Just to make sure it's understood "weak" attributed to :memory model: just means how concurrent with regards to reads and writes it is.
A quote[0]:
AND THEN THERE'S THE ALPHA
--------------------------
The DEC Alpha CPU is one of the most relaxed CPUs there is. Not only that, some versions of the Alpha CPU have a split data cache, permitting them to have two semantically-related cache lines updated at separate times.
This is where the address-dependency barrier really becomes necessary as this synchronises both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order.
And if you like the 'Java Memory Model' I'm not sure what your point really is, you're comparing a virtual machine with actual hardware.
The memory model is meant for developers - and how many&different memory barriers they have to issue.
That's bit much of stereotyping, depends I guess - "Java Concurrency in Practice" is one of the most sold books (when it comes to Java), and it covers some parts quite well. I have met quite a few folks that understand the matters pretty well, admittedly part of jsr-166. It was the "double-checked idiom" vs the original Java memory model is effectively what brought sane memory models even to C++.
>unless you cared about extreme performance
That's the whole purpose of the weak memory models. Albeit, they did fail to deliver - very error prone, close to impossible to debug, effectively outclassed by x86-64 and Sun Sparc (both being total store order), even arm-64 became "stronger".
That's because Java concurrency in practice is harder than it should be. I've seen plenty of teams struggling with what should be trivial problems trying to work their way around the various limitations and/or bugs in the JVM.
> Albeit, they did fail to deliver - very error prone, close to impossible to debug, effectively outclassed by x86-64 and Sun Sparc (both being total store order), even arm-64 became "stronger".
That's true, but at that time those weren't shipping 64 bit systems. It was pretty much R4000, Alpha or bust and the Alpha - even taking into account those limitations - worked surprisingly well for real world problems. In fact the systems that I'm talking about worked non-stop for more than a decade until they got de-commissioned and I never heard a single peep from those that took over the project that the memory model of the Alpha was somehow either a problem in practice or a concern.
Could it have been done better: sure, but with the knowledge of the time these seemed to be pretty reasonable choices and compared to what the alternatives were they were doing great. If anything the failure of the Alpha architecture is one of marketing more than anything. Pjlmp has some good information elsewhere in this thread, which pretty much corresponds with my experience of the time. There were some systems on the drawing board that were better in theory and they were still better in theory 10 years later, meanwhile DEC was shipping.
That they squandered their head start has nothing to do with the memory model, but everything to do with how they ran their business.
I've written a (small) OS for x86/32 just prior to getting my hands on an Alpha and compared to that the Alpha looked (and still looks) like a model of sanity to me (as does 68xxx). Just the number of tricks required to get an x86 system properly booted up is off the scale, you have to deal with a whole pile of memory insanity including repeated switches between modes (and memory models) in order to get your stuff even loaded. I spent weeks debugging that loader, to the point that I had a reset switch connected to a musical instrument foot pedal so I didn't have dive under the desk 10 times per hour to reset the box I was writing this on. If not for DJGPP to validate the 32 bit code ahead of time I doubt I would have been able to bring it up at all (note this was well before VMs became a thing on consumer hardware).
It's also pretty sane while also scaling to large systems as Azul's 768 core boxes showed.
Intel did not do that, IBM in this case managed to - and it had the cachet and name recognition to sell an product that was largely middling in a technical level, over other options that were often superior technically and cheaper.
Intel made a decent enough microprocessor, yes it was kludgy (even the 8086 was), but it performed well enough (I've never seen a claim that the 68000 significantly outperformed the 8086), and was available in quantity. The rest of the things that made the IBM PC a system that stormed the world were COTS parts assembled in an attractive package.
Now, could DEC have done all of that with the PDP-11, yes, absolutely - but the winds were prevailing against it because of the nature of DEC management - I fundamentally do not believe that DEC would not have allowed itself to ship something as 'flawed' as the IBM PC was.
I think you made a typo and meant 6800. Too late to edit though.
I make this typo too because the 68k was such a significant chip in history.
In the early 80s I moved from the MIT/128 ecosystem to the Stanford/101 ecosystem and even to my business-ignorant eyes (I was still in research at the time) and though I didn't understand why for years, it was like night and day.
I think that same transistor count was reached by Motorola on the 68020, which would've been around 1984, but would have needed the peripheral controllers mentioned here.
(If I recall correctly, it wasn't until the 486 that the FPU was incorporated.)
The larger issue with DEC was a strong NIH trend (almost as strong as IBM), I dont know if they could have bucked that trend to successfully launch a market winning PC. It probably would have looked like the DEC Professional, which I think looks like market failure.
So the dreams of a 64 bit extension to the PDP-11 might be stillborn ;-)
So probably not.
Suspect IBM's skunk work project was done as a hedge and anti-trust reasons. Personal Computers were going to take some business away from them they wanted it to be their product not someone else. Anti-trust also meant it needed to use off the shelf stuff.
DEC also did a "300 MHz 125 W ECL microprocessor" in the 90s, though that seemed to be mostly about developing cooling.
I might be biased but the company I worked for in the 80's switched to CMOS early[1]. I think the high end guys were ignoring CMOS despite it closing the gap relentlessly. Worse for all the other technologies as integration increased heat became a relentlessly and eventually unsolvable problem. I remember seeing ECL datasheets for simple chips that would draw a half watt.
Notable volume production of CMOS grew and grew while ECL, GA didn't really.
So yes, ECL for new business after 1985 was dumb.
[1] CEO realized enclosures, power supplies, and fans were a large fraction of the bom.
Which was fine while it lasted. But with VAX, the mini market became corporatised, inward-looking, nostalgic, even arrogant. Big-iron hardware had much higher internal prestige than VLSI - unfortunate, because DEC's VLSI people were the best in the world, and the systems software people weren't far behind.
DEC had absolutely no concept of VLSI-based mass-market commodity computing - no idea how to design it, build it, distribute it, market it, or even imagine it. The Rainbow was as close as it got, and that was a disaster.
So even with Alpha it had no chance. Prism would barely have changed that, because the problem was a failure of imagination in upper management.
BigCos should always have an internal team of annoying curious generalists to challenge orthodoxy and report annually on "What trends and opportunities are we missing?" Sometimes the C-Suite has the talent to do that, but more often it just doesn't.
Indeed and 486SX had the FPU disabled. I think that was the 1st time the binning/SKUs became a marketing strategy.
That was the end of our love affair with DEC. Very sad.
DEC tried to go after IBM and in doing so structured itself after IBM, it lead to multiple competing projects and groups doing similar work, multiple layers of management making the company unwieldy to manage, and a sales force that had trouble building the customer relationship because of internal structures.
The same thing functionally killed Motorola, and will eventually harm Cisco too (Cisco is a company that in my opinion is ripe for 'disruption').
Wikipedia says ~200k (https://en.wikipedia.org/wiki/Motorola_68020), so about 50% more than 135k.
I don’t know much of hardware, but part of that may have been because of (https://en.wikipedia.org/wiki/Motorola_68020#020_concept_eme...):
“A great debate broke out about how to refer to the underlying design of the new chip in marketing materials. Technically, the 020 was moving from the long-established NMOS logic design to a CMOS layout, which requires two transistors per gate. Common knowledge of the era suggested that CMOS cost four times as much as NMOS, and there was a significant amount of the market that believed "CMOS equals bad.”
They improved memory space because QBUS went from 64K (16 bits) to 256K (18 bits) to 4M (22 bits) but always usable only within a 64K window.
But I don't think it has way to resume instruction execution when encountering a memory trap.
You must be thinking of the VAX-11 where virtual memory was an explicit goal in its architecture (hence its name).
You can read more on the Gunkies site: http://gunkies.org/wiki/PDP-11_Memory_Management
So, what this article fails to really clarify is that the segment registers were now basically "selector" indexes into tables with base+length (in either pages or bytes) fields, execution permission controls. And these selectors and the GDT/LDT/IDT/TSS/call gates/task gates/etc were all designed to support OSs with a 4 level permissions hierarchy, user/library/driver/kernel (or similar), passing around access selectors which could do things like enforce the size of data structures, etc. And to support this, they added FS/GS so that all the general purpose registers could have their own permissions masks.
Pause for a moment and consider that again, Pointers (capabilities, aka selectors) can have not only a base address, but a hardware enforced limit, along with a permissions model that means a function like strcpy() would be incapable of writing to any memory that wasn't the target buffer or part of its own scratch space. Languages/os's could have enforced that called functions were unable to write to the callers stack, or even possibly run in their own completely separate stack. And that is just the beginning.
So, here nearly 40 years later the industry is still trying to recover from the mistakes of designing OS's and programming languages around flat memory models and simplistic user/supervisor permissions models. The 386 provided hardware assistance for writing OS's features that to this day aren't common.
ex: see CHERI.
There are only 8k possible pointers in the LDT, plus 8k in the GDT. The x86 segmented model isn't really suitable for implementing capabilities.
A limitation of 8 thousand different protection ranges would have been a lot for a program utilizing a few hundred KB of actual data and coming from a system were it was a PITA to access a data structure > 64K. It might not have been enough to do a super fine grained implementation, but it was more than enough for the time period, and had any significant OS's used it in a meaningful way I'm sure it would have been extended when limitations here hit, as was everything else in the following products.
Oh, and also one could have reloaded the GDT, or swapped some number of LDTs at some boundary if needed. It wouldn't have really been much more disruptive in the 1980s than switching the page tables on task switch, like every modern OS.
https://forums.grsecurity.net/viewtopic.php?f=7&t=3046
https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-se...
I have seen discussion that treats it as assumed knowledge that 68k was obsolete and needed to be replaced by powerpc. But it seems like conjecture - I have not seem technical arguments, and 68k seems like a cleaner architecture to ride forward than post-286 x86.
We never had intel chips. They were expensive. I had a Texas Instruments 286 and a cyrix 486 years later. The computer in my Dad's office were all "pc compatible" . This was a university (biology department in a God forsaken poor small city in Mexico). Someone got it bought because it was going to "change the world" (oh boy). We played TDCGA.EXE and PRINCE.EXE from its 2 51/4 floppy drives. No HDD.
We heard about apple's, commodore's and other crazy computers, but they were for "gringos" or rich people.
At the same time, we shared (pirated) software as if there was no tomorrow. Spread like wildfire. As and played the heck out of ID shareware.
Then you had the Mexican middle upper class: whose dad bought Macintosh one of those others. They NOW had to spend all this money to get it to do something (buy software). Nobody was pirating/sharing programs, and the PC ones just didn't work.
So a virtuous cycle continued and we kept buying x86.
Great memories! I'm glad I was part of that dawn of PC.
Sort of. There was the VME bus. An attempt to have a standards based bus that would work across vendors, and also for the the 88k cpu. It wasn't wildly successful, but was mildly successful.
Intel tried at least twice to move them away to i860 or Itanic and failed. So, improve x86 was the winning bet.
That said...the 386 was a world-changing engineering achievement, and as much as I think in a just and fair timeline the 68030 would have taken over the world ( :-) ), you can't discount what Intel did.
How the hell does _that_ happen? I've never had a job in 30 years where I didn't have somebody breathing down my neck to produce something tangible every couple of _days_.
I felt more spiritually connected to the MC68K line back when, for lack of a better term.
Amusingly the i386 system I spent the most time with was in college in 1993/4 on a Sun 386 tower running SunOS or Solaris in the APCS lab.
Really annoyed at myself that I got rid of in some fit of "well, I'll never use that again" cleaning some time.. especially given somehow still have "Sendmail, edition 2".
I might read the 386 book for nostalgia.. the Sendmail one..well, PTSD isn't something you get nostalgic about!
Beyond that there have been a few additions like CMOV (conditional move) that would be missed, though instruction fusion in pipelines can sometimes achieve the same speed up.
Lastly you would have to add some atomic instructions to support SMP.
* CMPXCHG (486). Central to multiprocessor synchronization and locking.
* CPUID (P6). Admittedly, if the instruction set were frozen you wouldn't need this... but if not, it's how you detect what CPU you're running on and what it supports.
* RDMSR/WRMSR (P6, kernel only). A general-purpose mechanism for adding extra special-purpose registers to the CPU without having to allocate an instruction to each one.
* INVD/WBINVD/INVLPG (486, kernel only). This was the first Intel CPU to support cache; these instructions were used to manage it.
The original Pentiums added CPUID, CMPXCHG8B, RDTSC, RDMSR, WRMSR, RSM to the instruction set.
Later Pentiums added the MMX instruction set.
Switching from a 386 to a 486 was bringing a huge speedup back then.
For one no one has mentioned that the 386 itself had no on die hardware floating point. That seems like a huge one.
Even if only a few instructions were added to the “core” some are huge like CMPXCHG, CMOV and although not an instruction itself the LOCK prefix.
But the extensions are huge. We don’t even still use the floating point instructions of the 386/387 era. MMX was pretty lame but SSE and AVX are critical. AES-NI is now necessary for most people with FDE commonplace.
From what I can tell, the 386 had the LOCK prefix. Pin 26 (bottom left) is LOCK# driven by the LOCK prefix [1]. But CMPXCHG is very useful and wasn't available until 486, and Pentium added some other stuff that's important.
[1] https://www.eeeguide.com/intel-80386-pin-diagram-description...
We under-appreciate how little binary compatibility matters now, so that you can even develop something on an ARM-based machine and then rebuild and safely deploy to an x64-based machine (usually because it's Node, JVM, Python, etc).
I did install Windows on it briefly from what I recall but wasn't impressed, there wasn't much to do with it. Games would be pure DOS and for programming I'd use Borland Pascal so again DOS.
But as a gaming machine it ran anything I could throw at it at the time, which was 286-games actually. Without realizing I had the absolute best "286" machine I could have, for DOS gaming it is apparently much better to play them on a 386: (Why you don't want a vintage 286 PC -- but I like mine anyway): https://www.youtube.com/watch?v=Htbvm5_NZHc
I paid $99 for Coherent because Linux didn't support the fancy RLL hard drive in my work computer. Eventually Linux caught up (or I got a new computer) and Slackware replaced Coherent (for little things like X11, better networking etc.). Those were the days :)
I had a 386DX, 25 MHz with 4MB and ran Slackware 3.0 with kernel 1.2.13 on it. It worked pretty nicely for me, but I have to say that I spent most of my time on the console. X11 did run but it was too slow to be fun.
Once Linux stabilized, the writing was on the wall...