What's so bad about Intel 8086 in technical terms?

[Hans_]

Most people here I guess finds the Motorola 68000 a really good design given the limitations at the time (economy, tech and market). The Intel 8086 and descendants were a less well thought design. But what specific technical aspects of it were made worse that any circumstance would had enforced?

I can think of some personal points:
 * Segmentation registers
 * Lacks the "MOVE" instruction?
 etc..

IIRC, the biggest problem with the 8086 was having memory divided up into segments/banks. This allowed the 16-bit CPU to access more than 64K,** but meant that programmers had to be very careful with setting the register that selects the bank before accesing memory. This made it a nightmare to program. To quote one of my university lecturers, "this set back programming by 10 years."

Fortunately, segmented/banked memory is long gone now.

Hans


** To put it another way, this allowed the CPU to access more memory without the expense of going to a 32-bit architecture.

[Hans_]

It's a bit of a blurry issue in any case, since x86 has been microcode running on top of a RISC microarchitecture since the Pentium Pro. Either that counts as an "emulator" and everything is emulated, or real mode is just another non-emulation mode of the processor - take your pick.

Microcode is normally seen as just another method of implementing a CPU. It's a method that's very common for CISC architectures. The 68000 CPU is also microcode based,** as is the original 8086. So, having RISC-like microcode doesn't make it an emulator. After all, otherwise you'd have to say that the 8086 CPU emulates the 8086 instruction set.

Hans


** IIRC, only the 68060 is hardwired; the rest of the 68K CPUs are microcode based.

[Hans_]

Segmented memory made address calculation more complex, but you have to be very careful setting any register before accessing memory on any cpu.
 
MOVE.W 6(A6), D0

If you don't set a6 correctly on 68000, it will fail as badly as not setting the ds/es segment correctly on 8086.

I don't understand your comparison. Of course you have to use the right address. However, at least you don't have the "oops, I'm writing to the wrong memory bank" problem that segmented memory creates.
 

Your lecturers quote sounds like hyperbole. The 8086 came out in 1978, the 68000 came out in 1979. There weren't any microprocessors ten years prior to that. Mini computers and main frames were still using segmented memory then. I'd be interested in what two years he thinks it was set back from and to and why.

Naturally it's a hyperbole, but one that was made to illustrate a point. Also, we're talking about a guy who has used mini computers and mainframes. Computer programming didn't begin with the first microprocessor...

EDIT: He may have said that IBM's decision to use the 8086 for the PC set back programming by about 10 years. It was a while ago, so I can't remember exactly what he said.

Hans

[Hans_]

Such techniques are still used in some operating system you know very well ;-)

I was expecting someone to make a snarky comment like this...

Yes, Extended Memory Objects bear a strong resemblance to segmented memory/memory banks, and it is a compromise.

However, unlike memory banks, mapping in an ExtMem object does not redirect the entire address space to the newly mapped memory. So accesses to all 2GiB of "normal" RAM go unimpeded; no bank switching necessary. That does make it less problematic, although developers should still heed Hans-Joerg's advice to treat it more like a file that's accessed by offset rather than as RAM.

Alas, on C64 you had to use memory banks to access all 64K RAM but for some reason 6502 and its descendants are not considered as "bad designs" like 8088/8086. Certainly 8088 was not too nice to program for but when I did some coding on 486 in Turbo Pascal it was not bad at all.

Possibly because the "C64 was cool." Or maybe because the 6502 & decendants didn't go on to become the core of mainstream computers.

Yes, a compiler can take care of the bank switching for you. Plus, the 80486 also had a mode allowing full 32-bit RAM access without switching.

Hans

[Hans_]

80386 had that already. 386 was actually quite decent chip unlike its predecessor, 80286.

Yes, the 386 already had it. Intel had a hard time getting people to use it, but the capability was there.

But to me, as a developer, it does not matter if there is bank switching involved or if CPU is using slower base+index segment memory model. Only user experience is important.

AFAIK, it did hurt the user experience early on due to the inevitable higher occurrence of bugs that it caused. It's easy to be dismissive when you're used to using compilers that hide these kinds of complexities and don't need to write hand-optimised assembly, but programmers weren't always so well equipped.

Hans