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

[psxphill]

The Pentium 4, known as netburst was discontinued.

Intel knew they had a problem with the P4 before it launched, they hacked the design up to make it work but that unbalanced the chip so that a lot of the design decision no longer made sense. Hyper threading allowed more of the chip to be utilised and they managed to hold on long enough for the core series to make it out of the door.
 
The P4 had a successor that was cancelled.
 

I doubt there is anything of the 8086 in there, except the real mode emulator that the chip boots in... Hmmm, that's only true if the system is using an IBM PC compatible BIOS... All my x86 machines use EFI, which AFAIK has no real mode code in it.

They all boot in real mode, EFI just switches to protected mode within the first few instructions.
 
No matter what mode it's in the cpu is executing instructions by translating them. So if you class real mode an emulator then protected or x64 mode is also an emulator.

[bloodline]

They all boot in real mode, EFI just switches to protected mode within the first few instructions.

Yes, I think you're right, I was wondering if there might be some nonresetable fuses that they might burn at the factory to disable the real mode booting... But I guess it just wouldn't be worth it.

No matter what mode it's in the cpu is executing instructions by translating them. So if you class real mode an emulator then protected or x64 mode is also an emulator.

Emulator isn't the right word obviously, when the CPU is running in whichever mode it's using a decoder for that ISA... I used the term emulator, as I'm not sure how closely the x86-64 architecture maps to the 8086, but a quick glance at the AMD docs shows clearly that a real mode decoder would fit comfortably in there.

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

[commodorejohn]

Emulator isn't the right word obviously, when the CPU is running in whichever mode it's using a decoder for that ISA... I used the term emulator, as I'm not sure how closely the x86-64 architecture maps to the 8086, but a quick glance at the AMD docs shows clearly that a real mode decoder would fit comfortably in there.

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.

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

[commodorejohn]

That's an entirely reasonable take on it, yep.

[psxphill]

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

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

[darkcoder]

Segmentation registers are somewhat similar to address registers in 68000

IMHO, it's not fair to say that. Differences are much more important than similarities.
Using Ax as base register of a segment is one of the addressing mode of 68000, while segment registers are *always* added to the "logical address" (using x86 parlance). This means that segmentation is an option for 68000 while is a constraint for 8086.

Plus, 68000 adress registers are much more similar to GRPs, you can use them as stack pointers, memory pointers, data variables.

Moreover, with the 80286 protected mode, segmentation registers can be protected and semantics changes completely, so it is clear that they have a very different function than that of 68000 adress registers. But maybe this is offtopic since the OP asked about 8086.

[itix]

Fortunately, segmented/banked memory is long gone now.

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

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.

[biggun]

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

Maybe historically it might make sense to start the comparison with the PDP-11?

The PDP-11 was first.
The 8086 could be regarded as inpsired by PDP-11 but with limitations...
Also the 68000 could be regarded by elements of the PDP-11.

The x86 has MOV but it can only do either "mem to reg"  or "reg to mem" it can NOT do the "mem to mem" like the 68000.
This is both a limitation as also a big advantage for the x86.
Speed wise doing two instruction (mem),reg and reg,(mem)
is the same as doing one (mem),(mem) as  the limiting factor is the memory access.
The disadvantage of the x86 here was to have 2 instructions needed.
This makes the code sometimes a little bigger.
The big advantage was that this simpelr encoding
was much shorter therefore the code could save a lot of space.

The 68000 being 32bit was much more flexible than the 8086.
But the x86 "improved" and when you later compare the 486 and the 68030 -
The x86 was not that bad anymore....

[commodorejohn]

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

The big problem wasn't even with assembler - as you point out, one more register to set isn't a huge deal when you're already directly working with registers all the time. The big problem was that it did awful things to higher-level languages - most 8086 compilers have distinct memory models you have to select based on whether you want more than 64KB for code, data, stack, or any combination thereof, and have distinct types for near (same-segment, 16-bit) or far (different-segment, 32-bit) pointers - which plays merry hell with C, where pointers and pointer manipulation are a way of life. They also frequently didn't allow arrays larger than 64KB (not a big deal in C, where arrays are just a special case of pointer and you can just use far pointer arithmetic almost interchangeably, albeit at a speed penalty, but a much bigger problem in less flexible languages.) And thanks to the incorporation of this kind of thing into the Windows API, programmers were stuck dealing with it even when the 386 had made it theoretically obsolete - it wasn't until Windows 95 that the stink of segmented addressing was finally washed off.

Also, some minicomputers and mainframes did use segmented memory, but most of them weren't designed that way from the ground up the way the 8086 was (the PDP-11, for example, originally only had a 16-bit address bus, and wasn't provided with an MMU until later - same goes for the TI-990.) They're kludgy because that functionality was actually a kludge; the 8086 was weird and balky right from day one.

[freqmax]

@psxphill, What's so special about A6 on m68k?

Moreover, with the 80286 protected mode, segmentation registers can be protected and semantics changes completely, so it is clear that they have a very different function than that of 68000 adress registers. But maybe this is offtopic since the OP asked about 8086.

I find the 286 etc interesting too

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.

6502/6510 didn't have any segmentation to wreck the program flow at its very core. ROM switching was more of an opportunity to get access to all that 64 kB of RAM.

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.

Coding in any high level language tend to isolate the user from intrinsics of the CPU.

What about little endian on x86? I have always found that really annoying.
(oh and that segment vs pointer collision in C was hell)

[biggun]

What about little endian on x86? I have always found that really annoying.

Historically little endian was a real advantage.

Lets give an example:



lets say you have in your register this number:
$11FF

And you want to add from memory this value
B: dc.w $0001

Lets say your register is 16 bit and your memory bus 8bit and your ALU can do 8bit per cycle.

A big endian machine needs to read the memory content
= 2 bus cycles
then it can add
= this takes another 2 cycles


For little endian the value look like this
B: dc.w $0100

A little endian machine can read the first byte "01" and add it right away, then it gets a carry out.
in the next cycle it can read the next byte add it using the carry.
This means the little endian machine can save 1 cycle compared to the big endian machine

[freqmax]

There's no performance enchancing technique to get around it?
I guess m68k suffers from an extra cycle?

[biggun]

There's no performance enchancing technique to get around it?
I guess m68k suffers from an extra cycle?

Well in 1979 this was a small advantage.
When you had 32 bit registers, and 16bit memory.

[psxphill]

The big problem was that it did awful things to higher-level languages - most 8086 compilers have distinct memory models you have to select based on whether you want more than 64KB for code, data, stack, or any combination thereof, and have distinct types for near (same-segment, 16-bit) or far (different-segment, 32-bit) pointers - which plays merry hell with C, where pointers and pointer manipulation are a way of life.

I never had that much of a problem with memory models in C. I thought SAS/C also had the concept of near and far pointers.
 

Also, some minicomputers and mainframes did use segmented memory, but most of them weren't designed that way from the ground up the way the 8086 was (the PDP-11, for example, originally only had a 16-bit address bus, and wasn't provided with an MMU until later - same goes for the TI-990.) They're kludgy because that functionality was actually a kludge; the 8086 was weird and balky right from day one.

The 8086 was mainly designed by one person & based in part on the 8085 architecture. You can call it a kludge all you want but the compromises made it commercially successful.
 
The iAPX 432 was their proper cpu, which was a failure (like all proper projects tend to do).
 
The history of the 80xx series is interesting http://research.microsoft.com/en-us/um/people/gbell/computer_structures_principles_and_examples/csp0631.htm The 8008 that started the series off was a contract to put a TTL cpu into a single package, which I think Intel just did the design shrink and the manufacture was done by TI.
 

There's no performance enchancing technique to get around it?
I guess m68k suffers from an extra cycle?

68000 doesn't allow unaligned access for 16 bit fetches, so all 16 bits will be available in one read. I don't know if the 68008 stalls until the 16 bits are fetched or whether it can start working with partial results, I suspect it stalls though.