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

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

[itix]

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

Sometimes when you have to edit memory layout manually it is. Like ARGB pixmaps are actually BGRA pixmaps. :-)

But in normal coding you never stumble on endianess.

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

[psxphill]

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

People wanted a more advanced chip that could have CPM software easily ported to it and then easily multitask. The 8086 is a good design for that requirement. The original IBM PC came with either 16k or 64k, so segments were still not a major issue.
 
I don't think anyone predicted how successful the PC would be and how important backward compatibility would become. Until dos extenders came along you had to deal with segments, expanded and extended memory. Any decent programmer wasn't spending an appreciable amount of time on that though.
 
It was successful because it was good enough. People don't care that programmers have to spend an extra 5 minutes a day writing their code.

[commodorejohn]

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

[psxphill]

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

It was more complex, for certain things & those things aren't always necessary even in big programs. The 8086 wasn't designed for large data, because the applications it was designed for wasn't using a lot of ram at the time.
 
Ugly is an emotive term and we're having a technical discussion.

[commodorejohn]

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

[biggun]

The P4 had a successor that was cancelled.

Yeah, do you recall their marketing talks when they
announced that their next Gen Pentium will reach 10 Gigaherz ?

[psxphill]

I'm not going to play at being some kind of impassive robot thing.

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.

[whabang]

Yeah, do you recall their marketing talks when they
announced that their next Gen Pentium will reach 10 Gigaherz ?

It is definitely technically possible - I mean, they did sell a few machines with factory-overclocked P4EE's running at over 4 GHz. Add the fact that Netburst was fairly decent as long as you didn't try to use it for too many things (ridiculously large pipelines) and you have a decent CPU for video encoding and so forth.

Not that it'd be of much use today, when we'll just do it with the video card instead.

The problem with scaling was that the power consumption and heat emission was quite insane. Some of the later Netburst CPU's have been clocked extremely high, and it would be expected that theey could have increased speeds even further if they'd continued developing the architecture.

That being said, I'll rather stay at 2.5-3 GHz with a few extra cores if it saves power compared to a 10 GHz single core.

As for the 8086, I dunno. I'm not old enough.

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

[psxphill]

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.

I don't know what the assessment of the technical issues are, because you just keep repeating that it's ugly. 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. And yes, emotions generally do make you make incorrect assessments. Which is why people end up in harmful relationships, or become addicted to drink/illegal substances/etc.
 
Many people can cope with discussing things rationally, not just fictional science officers.

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

[ElPolloDiabl]

8086: an ugly machine
RISC CPU: A streamlined work of art

Those are the type of comments people made about them.

[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