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

161–170 of 180 posts

Re: Intel 80386, a Revolutionary CPU

#161

Post by gpderetta »

adrian_b wrote: post #157
gpderetta wrote: post #150

Earlier quoted context omitted.

Well you mention that you can implement all programs, I just wanted to clarify that there are indeed some algorithms that cannot be implemented. 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.

I am curious to hear an example where a lock-free algorithm is needed for correctness, because I have never encountered any such case and this does not seem possible. 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 th…

Again, nothing to do with performance.

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.

Re: Intel 80386, a Revolutionary CPU

#162

Post by adrian_b »

gpderetta wrote: post #161
adrian_b wrote: post #157

Earlier quoted context omitted.

I am curious to hear an example where a lock-free algorithm is needed for correctness, because I have never encountered any such case and this does not seem possible. 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 th…

Again, nothing to do with performance. 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,…

An interrupt handler may use neither lock-based methods nor lock-free methods, because it may not remain stuck in a wait loop as required by the former and it may not use a CAS instrution as required by the latter, because any CAS instruction must be retried when it fails.

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.

Re: Intel 80386, a Revolutionary CPU

#163

Post by clausecker »

dboreham wrote: post #76
WalterBright wrote: post #34

Earlier quoted context omitted.

The DEC Rainbow would have been fine if they didn't do things like require special floppy disks that cost $5 each. 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'm a big pdp-11 fan but this wouldn't have worked because 128K address space isn't enough even in 1975. Listen to Dave Cutler talk about this in the 3h long interview.

The PDP-11 had virtual memory in later models and could address more real memory than the 8086 afaik.

Re: Intel 80386, a Revolutionary CPU

#164

Post by clausecker »

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…

The whole segmented protected mode stuff was introduced with the 286 already. The 386 only added FS/GS and grew segments to 32 bits.

Re: Intel 80386, a Revolutionary CPU

#165

Post by gumby »

WalterBright wrote: post #54
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?

If Intel could do it, DEC could do it.

Except the difference was Grove vs Olsen. Both were engineers, both built great hardware, but Grove feared his competitors and his customers' fickleness while Olsen was about beating / carving off business from IBM.

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.

Re: Intel 80386, a Revolutionary CPU

#166

Post by gumby »

Aloha wrote: post #154
WalterBright wrote: post #54

Earlier quoted context omitted.

If Intel could do it, DEC could do it.

Making the microprocessor is just one challenge - you have to produce a workable system that someone wants to buy (aka, is cheaper or more attractive than the other options. It does appear that DEC could have made a single chip PDP-11 in 1980, and probably could have made one with an expanded address space to get around the memory limitations in the PDP-11. Intel did not do that, IBM in this case managed to - and it…

> I've never seen a claim that the 68000 significantly outperformed the 8086...

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.

Re: Intel 80386, a Revolutionary CPU

#168

Post by gumby »

mschuster91 wrote: post #27
kristopolous wrote: post #26

Earlier quoted context omitted.

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…

Yeah but that was only made possible by Apple's unique circumstances: their close control over the entire tech stack, their experience with architecture transitions (PPC->x86-32->x86-64->ARM) and the required tooling (Rosetta, fat binaries, compilers), their relatively small market size, their expertise in developing with/for ARM from iOS, and enough cash in hand to buy out the entire fab capacity of TSMC. In the Win…

> unlike Apple, who famously cut ties with NVIDIA because NV didn't want Apple to write drivers for their GPUs

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

Re: Intel 80386, a Revolutionary CPU

#169

Post by Narishma »

kjs3 wrote: post #18

Maybe just me, but this sounds pretty revisionist wrt 'most important'. If the 8086/8088 hadn't stumbled into ubiquity via the IBM PC, there probably never would have been an 80286 much less an 80386. YMMV. 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.

The 386 maybe, but the 286 was already completed by the time the IBM PC launched if not before.

Re: Intel 80386, a Revolutionary CPU

#170

Post by Aloha »

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…

If you read the commentary from the folks who did the PC, the largest thing driving COTS was cost and time to market - while I'm sure anti-trust was a consideration at IBM, I dont think it was a primary one.
Post reply on HN