It "outperfromed" so well that even in the beginning of 90ies people were still struggling with ms-dos trying to push drivers/etc. outside main 640 kbytes as to be able to run some memory-hungry apps. Different "windowses" were keeping disastrous 'real mode' compatibility until the last of the heir, windows me, disappeared from sight.

@lvd That issue is not due to the segmented architecture of 8088/6 but due to the IBM design and limits of 16 bit address space. 80286 would allow enough memory for the time if you had a better OS. Segmentation was useful for debugging - set every malloc to allocate its own segment then if something overwrote it you got a nice crash in the debugger to see exactly what happened.

"Outperformed" in which respect? I seem to recall that in the early / mid 80s, 68k was the go-to architecture for workstation class computers, followed by various RISC designs in the late 80s / 90s. It wasn't until 2000 or so that performance computing moved to x86.

@lvd Sounds like comparing apples to oranges. Usage of DOS (based) systems as user requirement hampering performance isn't an issue of CPU structure - nor is platform design (IBM-PC). Not to mention most people in PCs back then buying a generation or two behind development. I

@MichaelGraf as in raw computing power. It always works (mostly) linear with RAM bandwith. x86 features quite compact code (nicely shown inthis paper comparing architectures from 6502 all the way to mainframe. Here 386 code is always more compact as 68k (remember, CPU spend more time reading code than data). At the same time the x86 bus interface is better in utilising bandwidth due code prefetch. A classic Doppelwumms :) x86 workstations aways outperformed 68k. The 2000s even allowed cheap ass consumer PC to do as well.

See my comment above. Jonathan Sachs disagreed with you. Perhaps it's because Lotus hopped on the PC bandwagon before the tools were adequately helpful.

@JohnDoty Not really sure what (dis)agreement. Also, note that Mr. Sachs comment seems to be about PC memory design, not the CPU segmentation. In case of Lotus it's safe to assume that this comment is not even about the PC itself, but LIM/EMS, a banked memory extension scheme developed by Lotus. Accessing more memory than the CPU can naturally address is always painful - and not related to segmentation. In fact, it's CPU agnostic. It hurts the very same, no matter if Apple II >48 KiB (was even worse than LIM) or any CP/M 3.0 >64 KiB.

Yes. x86 couldn't naturally address a reasonably sized memory for the time. Other contemporary architectures, particularly 68k, didn't have this limitation.

@JohnDoty Regarding x86 and workstations you seem fall for the same fase comparison between workstation and IBM's PC. Kind of comparing an Apple II with some workstation doesn't work either. There have been quite some incredible, fast and successful x86 workstations. Like the 1982 PC-X, an 8 MHz 80186 Unix workstation. Literally running circles around an Apollo DN100 or Sun-1. We had all three in office at the time for evaluation. (also considerable cheaper, despite carrying a Siemens price tag)

@JohnDoty Well, yes, that memory is that's exactly the same point as with a Apple II or CP/M. if one's sales pitch is to sell software that needs a lot of memory to customers having machines not made to provide for that memory, the complaints are rather pointless. It's exactly that why they earned so much money: Selling baggage racks for VW Bugs...

@MichaelGraf: Both the 8086 and 68000 were available in 8-bit bus versions; I'd rank the performance of different platforms with comparable memory speeds as 68008 < 8088 < 68000 < 8086, but the 68008 and 8086 were less common than the 68000 and 8088, meaning most first-gen 68000-family machines were faster than first-gen 8086-family machines.

Yet I've never heard of a PC-X. Sun, on the other hand, was quite successful. Why did it fail?

What false comparison? The workstation makers could have chosen x86. None of the successful ones did. Why?

Apple II is irrelevant: the 6502 was of the previous generation.

I would suggest compare 8086 and 68000 on some real task connected with large amounts of code (>>64k) and large amounts of data to manipulate. I don't think compact but flawed 8086 will be able to maintain its synthetic seeming advantage.

@mmmmmm it is essentially about "segmented" architecture of 8086: Given IBM would select a CPU without segmentation cancer, the cpm-like "OS" for that would support large memory from the very beginning and then the majority of problems I've described would simply not exist at all. What we had in our reality is a good indication of how a transient minor cost optimization would lead to almost two decades of technical misery and suffering everybody had to fight against. Only with (already cancelled) x86s suggestion from intel we could finally bury that filthy 8086 legacy.

@lvd the issue is not segmentation but each segement having a limit in size and that only affected some apps e.g. video and photos most apps do not deal with large blocks of data.

@mmmmmm in 1981 -- maybe, in 1991 -- certainly every app deals with large blocks of data. How coincindental that one of the recent questions here just confirms my PoV: retrocomputing.stackexchange.com/questions/31263/…

@lvd Yes apps needed a lot of data but many did not require all that data to be in one segment. I wrote programs that had complex linker setups and also ran oput of data memory. A 386 extender made that so much easier just recompile and link but the data was not one large block. I know as I debugged it under OS/2 1.x with each malloc beingh a separate segment.

How much is your "many"? And then, how many of your "many" apps could have been rewritten or written from scratch in a more effective, faster and concise way without trying to deal with that 16-bit segmented misery?