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

[commodorejohn]

Ugly segmented architecture, slow memory addressing coupled with a smallish register file, just enough orthogonality to trick you into thinking orthogonally only to be confronted with all the stupidly special-purpose register functions, and the added insult of all of that being to achieve not even binary compatibility with the 8080, but only source-compatibility. Bleah.

[commodorejohn]

And the rational for IBM using an 8088 rather than the 8086?  Well other than usual...

Just the usual: 8-bit support components were cheaper than 16-bit ones.

[commodorejohn]

Actually the Core line was derived from the Pentium M, which was basically a Pentium III with a DDR bus. Pentium 4s were Netburst, which was so bad that they pretty much abandoned it after that.

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

[commodorejohn]

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

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

[commodorejohn]

I never had that much of a problem with memory models in C.

Well good for you, then.
 

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.

I never argued that it wasn't commercially successful - it's just ugly.

[commodorejohn]

I also never claimed that there weren't reasons for the ugliness - but it's still ugly.

[commodorejohn]

Ugly is an emotive description of technical design compromises. I'm not going to play at being some kind of impassive robot thing.

[commodorejohn]

Then your value in any technical discussion is going to be limited.
 
Like if we were talking about Ford cars you'd be screaming at the top of your lungs about how Ferrari's are so much better.

That's not even remotely how that works. I don't have an opinion on technology because I have emotional reactions to it, I have emotional reactions to it because I have an opinion on it - and one that I've quite clearly elucidated on in this very thread. That's the best any squishy, organic, hormonal human being can manage.

But whatever, you just keep insisting that the fact that I display emotional reactions proves that my assessment of the technical issues that induce those reactions must be wrong, Mr. Spock.

[commodorejohn]

I don't know what the assessment of the technical issues are, because you just keep repeating that it's ugly.

For those who weren't paying attention...

That isn't a technical term for why 8086 is "so bad", how much of an emotional reaction you have says more about you than the design of the 8086.

Which is why I provided my technical assessment in those posts that you evidently either didn't read or forgot about before claiming that I only railed against ugliness in purely emotive terms.

[commodorejohn]

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.

As did the 386 - unfortunately, it took a good long while for the OS to catch up.

[commodorejohn]

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

Well, they had a hard time getting DOS and Windows to use it, on account of the PC BIOS, MS-DOS, and pre-NT/95 Windows being designed for real mode. Xenix supported protected mode all the way back in 1987.

[commodorejohn]

ARM's getting to the point of being quite adequate for users who don't require a high-performance gaming machine, though - and it does it at a lower price and a lot less power consumption. Its biggest handicap is that the only software support it has outside of iOS and Android is experimental nerd OSes like the free Unices, AROS, or RISC OS. Interesting stuff to be sure, but nothing that could make it a serious competitor in the general market.

[commodorejohn]

Nothing stands in the way of progress more than "good enough".

But, but, but bloodline! Don't you know that Worse is Better? People on the Internet said it, so it must be true!