Meanwhile, roughly contemporaneously, the Motorola 68000 was a CPU with 32-bit registers and a 16-bit bus (there was also the 68008 which had an 8-bit bus) - but in the 80s both the PC and 68000 devices were generally referred to as 16-bit. I guess the argument is that the 8088 was a cut down 8086 (an unambiguously 16-bit CPU) while the 68k family didn't ship a 32-bit bus until the 68020, but it's interesting how handwavy terminology is here (see also the "64 bit" Atari Jaguar)
808x registers are all 16 bit, despite it having a 20 bit address space. That means you can't fit a full memory address in a single register, which means memory is split into 64K "segments" and you have a separate segment register that tells the CPU which segment you're referring to (segments can overlap, so this is distinct from banked memory). On its own that makes writing 808x code fucking miserable.
Any programming in real mode with compilers meant that the programmer had to annotate pointers with near, far and huge. Plus you had to know if the stack segment was the same as the data segment...... ARRRRGGGGHHH.
I am glad that time is in the distant past now, although apparently plenty of brain cells remain dedicated to the 8088.
Indeed, this aspect of early x86 is something more people need to know about... It still has its remnants in low-level code. Of course, 6502 and other 8-bit processors had similar issues tryign to go beyond the 64K addressing limit, but only the x86 line both baked this into the architecture and continued to carry it forward for compatibility for many years.
Its kind of funny, in a history panel of Intel they badically talk about how they lost this generation. The Z80 and 6502 were beating them almost everywhere. Logically IBM should have used the Z80 but they didn't most likely because Exxon was at that time trying to attack IBM and Exxon was a major investor in Zilog.
Meanwhile, roughly contemporaneously, the Motorola 68000 was a CPU with 32-bit registers and a 16-bit bus (there was also the 68008 which had an 8-bit bus) - but in the 80s both the PC and 68000 devices were generally referred to as 16-bit. I guess the argument is that the 8088 was a cut down 8086 (an unambiguously 16-bit CPU) while the 68k family didn't ship a 32-bit bus until the 68020, but it's interesting how handwavy terminology is here (see also the "64 bit" Atari Jaguar)
In the Atari ST article from yesterday I read the 68000 was very pleasant to program for. I wonder how does it compare to 808x?
808x registers are all 16 bit, despite it having a 20 bit address space. That means you can't fit a full memory address in a single register, which means memory is split into 64K "segments" and you have a separate segment register that tells the CPU which segment you're referring to (segments can overlap, so this is distinct from banked memory). On its own that makes writing 808x code fucking miserable.
Any programming in real mode with compilers meant that the programmer had to annotate pointers with near, far and huge. Plus you had to know if the stack segment was the same as the data segment...... ARRRRGGGGHHH.
I am glad that time is in the distant past now, although apparently plenty of brain cells remain dedicated to the 8088.
Indeed, this aspect of early x86 is something more people need to know about... It still has its remnants in low-level code. Of course, 6502 and other 8-bit processors had similar issues tryign to go beyond the 64K addressing limit, but only the x86 line both baked this into the architecture and continued to carry it forward for compatibility for many years.
For those interested, the start of much of this was Federico Fagin with the 4-bit 4004 and its immediate successors https://en.wikipedia.org/wiki/Federico_Faggin
Its kind of funny, in a history panel of Intel they badically talk about how they lost this generation. The Z80 and 6502 were beating them almost everywhere. Logically IBM should have used the Z80 but they didn't most likely because Exxon was at that time trying to attack IBM and Exxon was a major investor in Zilog.
2017
Updated, thanks!