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

141–150 of 180 posts

Re: Intel 80386, a Revolutionary CPU

#141

Post by MichaelRo »

nu11ptr wrote: post #31
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 SX may have been slower, but it could still run all 386 software which was a huge advantage over the 286. I had a 16MHz 286 and I so badly wanted a 386SX 16Mhz so I could run 32-bit software.

Superseding a ZX-Spectrum, luckily my first PC was a Siemens-Nixdorf 386-SX @ 16 Mhz, no FPU, with 2 Mb of RAM and a 40 Mb hard drive: https://www.ebay.com/itm/172038842293

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

Re: Intel 80386, a Revolutionary CPU

#143

Post by adrian_b »

gpderetta wrote: post #136
adrian_b wrote: post #109

Earlier quoted context omitted.

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…

I don't think exchange is enough to implement all (or even most) lock-free/wait-free algorithms. CAS (i.e. lock cmpxchg), or an equivalent primitive in power, is needed. XCHG is enough to implement a mutex though, which is what most applications need.

Lock-free and wait-free algorithms are not necessary for any computing task.

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

Re: Intel 80386, a Revolutionary CPU

#144

Post by jhoechtl »

jacquesm wrote: post #93
zozbot234 wrote: post #71

Earlier quoted context omitted.

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

Disabling interrupts is a privileged operation (you need IOPL for the ability to execute the cli or sti instructions). Atomics can work even outside of privileged code. 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.

cli

jmp far $-4

Re: Intel 80386, a Revolutionary CPU

#145

Post by cesarb »

adrian_b wrote: post #109
zozbot234 wrote: post #71

Earlier quoted context omitted.

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

> i.e. LOCK XCHG with the Intel mnemonics.

Didn't all XCHG with memory operands have an implicit LOCK prefix on Intel 8086?

Re: Intel 80386, a Revolutionary CPU

#146

Post by adrian_b »

cesarb wrote: post #145
adrian_b wrote: post #109

Earlier quoted context omitted.

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…

> i.e. LOCK XCHG with the Intel mnemonics. Didn't all XCHG with memory operands have an implicit LOCK prefix on Intel 8086?

Only since Intel 80286 (1982).

On Intel 8086/8088 and 80186/80188 an explicit LOCK prefix is required.

Re: Intel 80386, a Revolutionary CPU

#148

Post by hulitu »

tyingq wrote: post #131
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.

>Were there any commercial efforts to build IDE, VESA or PCI systems around a 68k processor? 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.

There was also Apollo. They had the Domain 3000 series pretty close to PC architecture (ISA bus). Unfortunately, HP ate them.

Re: Intel 80386, a Revolutionary CPU

#150

Post by gpderetta »

adrian_b wrote: post #143
gpderetta wrote: post #136

Earlier quoted context omitted.

I don't think exchange is enough to implement all (or even most) lock-free/wait-free algorithms. CAS (i.e. lock cmpxchg), or an equivalent primitive in power, is needed. XCHG is enough to implement a mutex though, which is what most applications need.

Lock-free and wait-free algorithms are not necessary for any computing task. 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…

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.

Post reply on HN