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

111–120 of 180 posts

Re: Intel 80386, a Revolutionary CPU

#111

Post by xxs »

jacquesm wrote: post #110
xxs wrote: post #108

Earlier quoted context omitted.

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

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

Re: Intel 80386, a Revolutionary CPU

#112

Post by weinzierl »

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)

Coherent sounds really cool, I've never heard of it before. I wish I had known about it back in the day.

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.

Re: Intel 80386, a Revolutionary CPU

#114

Post by formerly_proven »

varjag wrote: post #103
Gibbon1 wrote: post #79

Earlier quoted context omitted.

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.

Alpha and VAX 9000

DEC also did a "300 MHz 125 W ECL microprocessor" in the 90s, though that seemed to be mostly about developing cooling.

Re: Intel 80386, a Revolutionary CPU

#115

Post by formerly_proven »

jacquesm wrote: post #110
xxs wrote: post #108

Earlier quoted context omitted.

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

The "oh we can't make the cache as big as we'd like so we just make it two fully independent banks and bake the lack of synchronization of them into the ISA" in DEC Alpha very clearly falls into the "baking restrictions of today into the ISA", which virtually always turns out to be a bad idea.

Re: Intel 80386, a Revolutionary CPU

#116

Post by jacquesm »

formerly_proven wrote: post #115
jacquesm wrote: post #110

Earlier quoted context omitted.

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.

The "oh we can't make the cache as big as we'd like so we just make it two fully independent banks and bake the lack of synchronization of them into the ISA" in DEC Alpha very clearly falls into the "baking restrictions of today into the ISA", which virtually always turns out to be a bad idea.

That I'll be happy to agree with but compared to the 640 k limit it's clearly a manageable one, and one that end users of the system normally do not have to concern themselves with.

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

Re: Intel 80386, a Revolutionary CPU

#117

Post by jacquesm »

xxs wrote: post #111
jacquesm wrote: post #110

Earlier quoted context omitted.

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.

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

Your typical Java developer has zero knowledge about this and on the UNIX versions that shipped with the Alpha (for me, at the time that was RedHat) fairly elegantly hid that complexity to the point that you could just forget about it unless you cared about extreme performance. In my case the ability to address large amounts of memory and a filesystem that wasn't limited by the 32 bit limitation was the key factor and while it took another decade for x86 to catch up I was happily shipping.

Re: Intel 80386, a Revolutionary CPU

#118

Post by sweetjuly »

scrlk wrote: post #13
xattt wrote: post #8

Earlier quoted context omitted.

What’s their hope right now? Some sort of Quark-derived desktop CPU à la Dothan?

Doubling down on becoming a competitive foundry and becoming the western equivalent to TSMC. If their 18A process ships on time (2025), there's a chance that they could regain process leadership.

I can't imagine the US government letting Intel Foundry Services fail. Not so much in the banking "too big to fail" sense but a "national security interest" sense: not only are semiconductors critical to the domestic economy but having the latest nodes available for military application gives a major leg up. We see this elsewhere too; SkyWater is a kinda terrible fab (their yield for even very old processes is incredibly bad lol) but the DoD is still throwing gobs of money at them to developed their radhard process because they need some domestic, trusted vendor to turn to. IFS might not be competitive but they probably aren't going anywhere, even if they fail to deliver anywhere near on time.

Re: Intel 80386, a Revolutionary CPU

#119

Post by xxs »

jacquesm wrote: post #117
xxs wrote: post #111

Earlier quoted context omitted.

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

Your typical Java developer has zero knowledge about this and on the UNIX versions that shipped with the Alpha (for me, at the time that was RedHat) fairly elegantly hid that complexity to the point that you could just forget about it unless you cared about extreme performance. In my case the ability to address large amounts of memory and a filesystem that wasn't limited by the 32 bit limitation was the key factor an…

>Your typical Java developer has zero knowledge about this

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

Re: Intel 80386, a Revolutionary CPU

#120

Post by Gibbon1 »

varjag wrote: post #103
Gibbon1 wrote: post #79

Earlier quoted context omitted.

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.

My memory of the 80's was most stuff was fast but power hungry NMOS. People were pushing things like GA, ECL, Silicon on Sapphire as the next thing to replace it.

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.

Post reply on HN