Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel 80386, a Revolutionary CPU

xtof.info

Post reply on HN
Print view View original

101–110 of 180 posts

Re: Intel 80386, a Revolutionary CPU

#101

Post by jacquesm »

WalterBright wrote: post #78
Aloha wrote: post #75

Earlier quoted context omitted.

I think DEC's strong trend line of NIH (almost as strong as IBM) almost certainly dooms a PC-PDP - IBM only made the PC by effectively creating a skunkworks within the company that was focused solely on 'go to market' compared to the normal IBM development process. I dont know if DEC could or would have done that.

I was a DEC-head in the 70's and 80's, and along with my fellow DEC-heads anxiously awaited DEC's entry into the PC arena. Everyone was excited to see the rollout of the Rainbow, sure it would be a killer machine like other DEC machines. After the presentation, we were all in shock. It did not play to any of DEC's strengths, and was just a crummy, proprietary x86 insult. That was the end of our love affair with DEC.…

One of the worst own goals in the history of computing imnsho.

Re: Intel 80386, a Revolutionary CPU

#102

Post by jacquesm »

xxs wrote: post #85
WalterBright wrote: post #54

Earlier quoted context omitted.

If Intel could do it, DEC could do it.

DEC Alpha had the weakest memory model, which while cool to write for with its all memory barriers/concurrency - it's quite annoying to work with in the real world, a major reason while DEC failed.

Compared to the madness that was x86 memory models the Alpha was quite sane. I'm not sure what you base your 'weakest' on (it suggests a comparison with others) but when Alpha was released there wasn't much to compare it to besides the R4000 and that just as hard if not harder to source than the Alpha machines were. I had a bunch of them (SGI boxes of various plumage) and the OS hardly took advantage of the chip, but on the Alpha it all just worked at 64 bits out of the box.

Re: Intel 80386, a Revolutionary CPU

#103

Post by varjag »

Gibbon1 wrote: post #79
Aloha wrote: post #73

Earlier quoted context omitted.

The IBM PC had an advantage in that most of the support parts were IIRC largely jellybean 74 series logic - could a PC-PDP have used similar COTS parts? 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.…

I read an essay by a guy that worked on project to produce a DEC minicomputer using ECL logic. And there was yet another group working on the DEC Alpha. At the time the main group was using most of the companies resources betting the company on dethroning IBM in the main frame arena. And was trying to stab the Alpha and Minicomputer group in the back. So probably not. Suspect IBM's skunk work project was done as a he…

I can't imagine Alpha and ECL based designs being done anywhere within the same decade.

Re: Intel 80386, a Revolutionary CPU

#104

Post by jacquesm »

kristopolous wrote: post #26
mschuster91 wrote: post #21

Earlier quoted context omitted.

> and getting slaughtered in their only remaining stronghold by NVIDIA, AMD and ARM pillaging their castle 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…

Arm snatched Intel's hold on the Apple market and we can invoke any Clayton Christensen book on the Raspberry PI series. Maybe not the Raspberry PI 5, but what about say, the imaginary 8 or the 9 a few years hence? 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 chrome…

I have a Pi 400 here and for the money it's most impressive. It runs pretty much the whole house in terms of heating and power management, with full autonomy using HA and a very limited bit of custom stuff. You can stick in anything at all and it 'just works' the only things that have given me a headache are Zigbee dongles, everything else worked without issue.

Re: Intel 80386, a Revolutionary CPU

#105

Post by jacquesm »

dboreham wrote: post #91
hakfoo wrote: post #40

Earlier quoted context omitted.

The problem isn't even building NT for ARM/RISC-V/SH-4 or whatever, it's being able to reproduce enough of the surrounding universe that Windows on x86-64 has. 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 w…

I've been using an ARM Windows machine as a daily driver (when I'm traveling) for a year. I do that because it has much better battery life than any similar Intel machine, and it has integrated 4G.

How is the software support for that? What kind of machine do you have?

Re: Intel 80386, a Revolutionary CPU

#106

Post by jacquesm »

icedchai wrote: post #56
weinzierl wrote: post #28

The 80386 DX was a revolutionary CPU. It certainly foreshadowed the 486 and ultimately the Pentium. Most people I know only had a 80386 SX which was still revolutionary but it hid it well by being essentially a glorified (but slower) 80286 on the outside.

The 386SX could do everything the 386DX did, just slower. My first Linux box was a 386SX machine. Before Linux, I ran Coherent on it: https://en.wikipedia.org/wiki/Coherent_(operating_system)

Another Coherent fan here. That was an awesome system. And for once: awesome documentation. The Coherent book long outlived the Coherent system for me.

Re: Intel 80386, a Revolutionary CPU

#107

Post by varjag »

nxobject wrote: post #57
Aloha wrote: post #53

Earlier quoted context omitted.

Thats an interesting alternative history thought experiment. 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?

Hmm – the smallest, most highly-integrated PDP-11 (-compatible) package ever made was the QFP 1806VM2, with around ~135k transistors; it integrated MMU, UART, parallel interface, keyboard controller, etc, but did floating-point instructions in interpretive microcode. 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 controlle…

1806VM2 wasn't released until late 1980s when there were numerous superior options, even if your yardstick is transistor count (but naturally not in USSR).

Re: Intel 80386, a Revolutionary CPU

#108

Post by xxs »

jacquesm wrote: post #102
xxs wrote: post #85

Earlier quoted context omitted.

DEC Alpha had the weakest memory model, which while cool to write for with its all memory barriers/concurrency - it's quite annoying to work with in the real world, a major reason while DEC failed.

Compared to the madness that was x86 memory models the Alpha was quite sane. I'm not sure what you base your 'weakest' on (it suggests a comparison with others) but when Alpha was released there wasn't much to compare it to besides the R4000 and that just as hard if not harder to source than the Alpha machines were. I had a bunch of them (SGI boxes of various plumage) and the OS hardly took advantage of the chip, but…

>I'm not sure what you base your 'weakest'

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.
[0]: https://www.kernel.org/doc/Documentation/memory-barriers.txt

Re: Intel 80386, a Revolutionary CPU

#109

Post by adrian_b »

zozbot234 wrote: post #71
johnklos wrote: post #44

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…

> 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.

Already 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).

Re: Intel 80386, a Revolutionary CPU

#110

Post by jacquesm »

xxs wrote: post #108
jacquesm wrote: post #102

Earlier quoted context omitted.

Compared to the madness that was x86 memory models the Alpha was quite sane. I'm not sure what you base your 'weakest' on (it suggests a comparison with others) but when Alpha was released there wasn't much to compare it to besides the R4000 and that just as hard if not harder to source than the Alpha machines were. I had a bunch of them (SGI boxes of various plumage) and the OS hardly took advantage of the chip, but…

>I'm not sure what you base your 'weakest' 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"…

That's what allows the Alpha to be multi-processor.

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.

Post reply on HN