But the 68000 was released in 1979 with a 24-bit address bus...

My only beef with the choice of shifting by four is that in cases where code does need to normalize pointers, shifting an offset right by four bits requires either loading CL with four and using a rotate-by-CL instruction, or using four shift-by-one instructions, neither of which is at all efficient. Using an 8-bit shift would have made pointer normalization more convenient. While a 16-byte paragraph size does offer some advantages, using an 8-bit shift and ignoring the top four bits of each segment would have been in some ways more useful.

@StephenKitt The 68000 was Motorola betting on Moore's Law and the appeal of a more elegant approach. The 8086 was Intel betting on close compatibility with the established 8080 architecture and practical considerations in memory cost. We know who won.

While 1 MiB is a reasonable choise for a 16 Bit CPU - especially considering that it wasn't realy much faster than 8 bit machines of the same time - looking at RAM prices isn'T exactly an argument against.

@supercat Since 'normalizing pointers' is always evil, it doesn't matter if the granuality is 4,5 or 8 bit.

@Raffzahn: There aren't a huge number of situations where pointer normalization is appropriate, but there also aren't a huge number of situations where a 16-byte paragraph size offers much advantage over a 256-byte paragraph size. Either would have been a reasonable design, but with the 256-byte paragraph size adding the ability to extend the address space by moving the CPU to a larger package.

@supercat I know only one situation where normalisation is apropriate and that's when the CPU is missused. For a 16 bit CPU software needs to be structured arround the basic fact that it's a 16 Bit CPU, not something else. Everything else breaks compatibility with future releases - as the 286 did prove.

@Raffzahn: Normalization is necessary if one wants to manage a contiguous region of more than ~65520 bytes without requiring that all allocations be rounded up to 16-byte multiples. A similar shift-and-add sequence is necessary when performing DMA or other operations that require using physical addresses. If a 256x scaling factor were used and adjacent protected-mode segment selectors were numbered consecutively, code that expected to normalize pointers within a certain range could have been accommodated in practical fashion...

...simply by creating a sequence of segment descriptors whose base addresses were 256 bytes apart.

All this talk about normalization, segments, etc. is only minimally relevant in 1978 - and for a few years after that. Would it have been easier to write Lotus 1-2-3 and the other killer applications for the IBM PC/XT with a cleaner memory architecture? Absolutely. Did it matter for the average user? No! And a lot of the initial applications (and operating systems) for the PC - in 1982 - were ports of CP/M (as CP/M-86 and the far more popular MS-DOS/PC-DOS which was modeled on CP/M even if not (arguably) infringing upon it legally) - WordStar, dBase II, etc. Memory architecture matters to...

...the typical computer buyer about as much as plumbing to the typical house buyer - e.g., how many buy their house based on copper vs. PEX vs. PVC pipes? They buy their house based on square feet (think how much space can I afford, not what will the zoning board allow), location (if it is near where I want to be - like the computer that can run the software I want to run) then I'll take it. So the workstation buyers didn't use Intel chips - they used Motorola (and others - RISC designs, etc.). But the mass market just didn't care and Intel knew that - or at least hoped so.

"Three of the biggest pieces - then and now - are RAM, mass storage and CPU" -- although RAM much more so than now. Indeed, I'd say back in the late 70s / early 80s, manufacture of the PCB was almost certainly more expensive than most CPUs. In 1981, with the IBM PC launching, electronics retailers were selling the 8088 at $40, and 8086 at $60. 64K of RAM, however, would have been more like $100 (if you were willing to spare the board space to use the cheaper 4116 chips) to $160 (if you wanted 4164s). Obviously prices were lower in bulk - e.g. I've seen prices as low as $10 for 8088s.

@manassehkatz: The only major weakness in the 8086 hardware architecture for most purposes are the lack of general-purpose segment registers, and the omission of a few instructions like "load segment, immediate". Programming language support was a bigger issue, since neither C nor Pascal has any way of specifying that two pointers identify portions of the same allocation, allowing both to be used without reloading segment registers, unless both objects are in the program's one and only primary data segment.

@manassehkatz: While a 32-bit architecture like the 68000 may break the 64K barrier more conveniently than the 8088/8086, the 8086 does better than any 16-bit architecture I've encountered. Most other 16-bit architectures subdivide memory into rigid power-of-two-sized chunks and make it awkward to handle objects that cross chunk boundaries, but the 8088 can place objects up to 65520 bytes at any starting address. Otherwise, complaints seem to come from people who don't understand how to use the architecture effectively or are essentially complaining that it isn't a 32-bit processor.

@supercat - neither C nor Pascal has any way of specifying that two pointers identify portions of the same allocation -- I agree that this is a major omission in C, but it should be noted that Pascal it isn't possible to have two different pointers to the same allocation, as there is no concept of pointer arithmetic or of creating a pointer to an existing object (although some extended Pascals did at least allow the latter with the @ operator, but it was not a part of any Pascal standard).

@Jules: The name "Pascal" may refer to an anemic language with no extensions, a better dialect by University of California San Diego for the UCSD P-system, or to popular dialects made by Borland on the PC, or by Apple and Symantec on the Macintosh. The PC and Macintosh dialects all allowed programs to do various forms of pointer arithmetic (I've done it on those platforms), and I think the USCD Pascal did so as well (though I'm not sure if I ever used pointers at all on that platform).

@Jules; Upon a little further thought, a Pascal dialect for the PC which did not allow genera use of the "@" operator could have worked quite nicely on the 8086 if it had used two-byte "pointers" that only held the segment portion [assume all objects start at a constant offset]. Having a pointer type that can identify things other than heap allocations is very useful, so I suppose a good dialect would probably need to have two different kinds of pointer syntax to distinguish the two usages.

(By which I mean the compiler would do it, and presumably the linker would remove one or the other version if it turned out to be unnecessary)

@Jules: The common pattern for pointer arithmetic was to have a function which expects a pointer to an array and pass it the address of the start of a row of a 2d array. One might not normally think of that as "pointer arithmetic" as such, but it derives a pointer that doesn't identify the start of a heap object.

"640 kB ought to be enough for anybody." perhaps Intel thought the same