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

[freqmax]

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

[freqmax]

Are you sure?

The P4 was at least an expensive air heater.. hot air if you like
And then marketing seemed to learn that performance not Hz is the measure that the market uses.

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

[freqmax]

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

[freqmax]

The iAPX 432 was their proper cpu, which was a failure (like all proper projects tend to do).

Why did it fail?

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

One could also call it a judgment based on experience of good engineering.

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

BSD operating systems (or most unix:es) provided an abstraction on x86 to do away with the dysfunctional segmentation memory handling. Mainly by activating the protected mode memory model and provide a compiler environment that did away with it.

Really at this point in time there is no competition on the desktop/laptop. i5 and i7 far outclass anything offered by ARM, and there are no other practical competitors left.

Actually when you need a machine that perform as fast as possible per watt used then ARM beats Intel. This also goes for solder ability of the chip package and stable chip offerings. Intel has a habit of EOL:ing chips while you design a circuit board for them..

Also a single chip ARM is now approaching the capacity of an A500 with RAM of 192 kB vs 512 kB and flash/ROM of 1024 kB vs 256 kB. So you could fit the Amiga ROM + workbench into ONE ARM chip and use the powerful DMA circuits to do graphics and sound. And all that at 168 MHz for like 10 EUR. Neat!
(for serious stuff one needs more DRAM, but those 192 kB goes a long way..)

What Intel has going is an existing software base and knowledge from developers. Their processors are also most likely the fastest for single thread applications. In many cases the x86 platform is the cheapest performance per instruction per second too. But the platform is a hodgepod of bad compromises. They lately also left the open nature of the platform (UEFI, TPM, CPUID etc).

[freqmax]

I think the keyword here is Real-world-scenarios. Also the ARM can go really low in power consumption absolute terms.

(Dunno how MIPS fares in this)

[freqmax]

Off-topic: IBM was early with computing for commercial companies and thus had a foothold with business people (MBA beancounters). IBM wanted to a bite of the personal computer market so they throw together a team that put together some crappy chips from some crappy chip designer like Intel. They then tried to get CP/M but were too important to wait for a good deal so got a crap software to go with this design.

The next phase is that because they consider it an unimportant product they release drawings and documentation. Businesses buy it because (1) IBM reputation (2) cheap compared to mainframe. And then it takes of.

So what's needed for world domination is contacts and reputation..
x86 was bought by clueless MBA:s because it had "IBM" stamped onto it. Now the actual people doing the buying may be different people but the management culture still permeates. And once there was software for crap hw/sw the other software had to be compatible with the former which was used in the all important "business environment" ..

Take out the reputation and contacts from IBM in the 1980s and the problem would likely been a lot less severe. Add compability layer to other platforms to snuff out the compability aspect and there might be a solution. The current solution seems to be that x86 is to inefficient and Windows is just a too big blob of code for mobile environments where power and resources utilization really counts. Besides Microsoft was just too busy entrenching themself in a market that was soon to be competing with a whole new market they perhaps didn't "get".

[freqmax]

Makes you wonder what would have happened if the "PC" got an 68000 and CP/M to go with it

[freqmax]

Perhaps Amiga would have gone with MIPS and some more unix like sw?

[freqmax]

Seems the conclusion on x86 is that it was all haphazard and then nobody wanted to do a clean break. Well until smartphones forced the issue due power constraints.

[freqmax]

So now that processors have a frequency ceiling the businesses that stay with x86 will see their competitors run other stuff way faster due efficiencies ..

[freqmax]

Lets not forget MIPS..

[freqmax]

Microkernels are nice. IF the CPU sports a genereous on board cache and in general the architecture won't induce a performance penalty that microkernels seems to do.

Any tip for microcontroller BSD unix for MMU less stuff ..?
(ie run on 512 kB flash and some way less RAM)

[freqmax]

The 4.4BSD-Lite2.tar.gz source archive is 44.23 MB. I suspect one might run out of flash memory..

Perhaps 2.11BSD is small enough.

If the C64 can run Unix. Then surely an ARM cpu can too. But one might have to strip out a lot. The practical way is to use adress relocation table and trust programs to behave. And ofourse (ab)use the clock timers to create pre-emptive task scheduling.

[freqmax]

What would you classify ARM Cortex-M and ARM Cortex-A as?
(presumably v7 and higher)