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

121–130 of 180 posts

Re: Intel 80386, a Revolutionary CPU

#121

Post by sweetjuly »

nezirus wrote: post #95
StillBored wrote: post #66

I really wish people would stop applying the "flat 32-bit" revisionist history to the 386. That wasn't its obvious target, but rather picking up the important "capability" arch features which were seen as the future before unix/c/risc/single supervisor/ideas destroyed the previous 30 years of mainframe/minicomputer OS research in things like security. So, what this article fails to really clarify is that the segment…

It been long since I have stopped following grsecurity, but I would not be surprised if segment registers are still used (e.g. Pax UDEREF) https://forums.grsecurity.net/viewtopic.php?f=7&t=3046 https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-se...

I would be amazed of PaX still used segment registers seeing as they don't really do much in long mode. In fact, they specifically call this out in the description of UDEREF in your second link.

Re: Intel 80386, a Revolutionary CPU

#122

Post by StillBored »

bonzini wrote: post #80
StillBored wrote: post #66

I really wish people would stop applying the "flat 32-bit" revisionist history to the 386. That wasn't its obvious target, but rather picking up the important "capability" arch features which were seen as the future before unix/c/risc/single supervisor/ideas destroyed the previous 30 years of mainframe/minicomputer OS research in things like security. So, what this article fails to really clarify is that the segment…

> Pointers (capabilities, aka selectors) can have not only a base address, but a hardware enforced limit 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.

Sure, 40 years later, but for comparison my computer in 1990 had 1MB ram. Its replacement had 8M iirc a year or two later. I remember in the later 1990's having a problem with my socket7 computer because the caches couldn't physically tag more than 64M of ram, so everything above that was uncached. Linux of the mid 1990's would print a half dozen lines when one typed 'ps'.

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.

Re: Intel 80386, a Revolutionary CPU

#123

Post by jacquesm »

xxs wrote: post #119
jacquesm wrote: post #117

Earlier quoted context omitted.

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 b…

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

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.

Re: Intel 80386, a Revolutionary CPU

#124

Post by Someone »

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…

> I think that same transistor count was reached by Motorola on the 68020, which would've been around 1984

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

Re: Intel 80386, a Revolutionary CPU

#125

Post by cturner »

Intel evolved the x86 line beyond 386, into Pentium Pro and then to amd64. Why did Motorolla not do the same with the 68k?

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.

Re: Intel 80386, a Revolutionary CPU

#126

Post by monocasa »

flashback2199 wrote: post #68
flashback2199 wrote: post #47

Earlier quoted context omitted.

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

More 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

Which is probably one reason why he worked at Transmeta for a while.

Re: Intel 80386, a Revolutionary CPU

#127

Post by aforwardslash »

bonzini wrote: post #80
StillBored wrote: post #66

I really wish people would stop applying the "flat 32-bit" revisionist history to the 386. That wasn't its obvious target, but rather picking up the important "capability" arch features which were seen as the future before unix/c/risc/single supervisor/ideas destroyed the previous 30 years of mainframe/minicomputer OS research in things like security. So, what this article fails to really clarify is that the segment…

> Pointers (capabilities, aka selectors) can have not only a base address, but a hardware enforced limit 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.

8k LDT descriptors per task. Each LDT table also needed an entry in GDT, limiting the amount of tasks to also another 8k. So 64k descriptors total. Thing is, most ia32 operating systems dont actually use the existing hardware model for multitasking, and instead use simpler approaches that cater to the flat memory model.

Re: Intel 80386, a Revolutionary CPU

#128

Post by ndsipa_pomu »

cturner wrote: post #125

Intel evolved the x86 line beyond 386, into Pentium Pro and then to amd64. Why did Motorolla not do the same with the 68k? 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.

Not enough computers were sold using 68k to provide enough demand for the chips and so it couldn't compete with Intel on price and couldn't justify spending lots on research and development. Intel had the PC-compatible market and thus a huge demand for its chips.

Re: Intel 80386, a Revolutionary CPU

#130

Post by TheOtherHobbes »

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…

DEC always saw itself as the scrappy, sleek underdog in IBM's big iron market - an engineering company making relatively affordable tools for engineers, academics, and other qualified professionals. Where "affordable" meant six or seven figures instead of seven or eight.

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.

Post reply on HN