4 ms·

> classical bank-switched 16-bit CPU's of the 1970's, like the Zilog Z80, Motorola 68000, or MOS 6502. Hang on a cotton-pickin' minute. This is mixing up 3 di

> classical bank-switched 16-bit CPU's of the 1970's, like the Zilog Z80, Motorola 68000, or MOS 6502. Hang on a cotton-pickin' minute. This is mixing up 3 different things. 1. 6502 and Z80 were 8-bit, not 16-bit. 2. 68000 is a 1970s chip but it doesn't belong in there with those 2. Its peers were the 65816 and maybe the Z800. The one that would belong was the 6800 or 6809. 3. 6502 and Z80 were both used in machines with bank-switching, but the CPUs themselves couldn't do it. They needed the chipset to do that, and the early 8-bit micros didn't have that, so their 16-bit address bus limited them to 2^16 bytes of RAM: 65535 bytes, meaning 64kB. I think part of the brilliance of the 8088/8086 was that it brought the bank-switching logic on board and into the instruction set, so it was in some ways a sort of 8-bit chip that could natively handle 1MB of memory space... clumsily, via 16 separate 64kB blocks, but what mattered is that it could do it at all.

csense 2y ago
1. I was using the modern definition of a processor's "bitness", i.e. the size of a memory address. (Modern x86's are considered "64-bit" even though you can use up to 512 bits at once with AVX instructions. To be fair, you're absolutely correct: These chips were assigned "bitness".) 2. I'm not super familiar with Motorola; I'll defer to you on this one. 3. Yes, I know. My point is that a modern developer used to programming in a flat address space, upon learning about segments for the first time would say "Ewww, why did they do it that way? Madness!" But if you consider the history of bank-switched systems, segments make a bit more sense. But the madness is lurking under the surface. "Why does the DOS memory allocator always give me the beginning of a segment no matter how much I allocate?" I once asked. "Isn't it incredibly wasteful to always give you 64k regardless of how many bytes you request?" Only much later did I find out that the x86 only supports 20-bit addresses and internally runs the calculation phys_address = segment*16 + offset. "Each segment is its own private 64k" was the natural (wrong) mental model I'd constructed; "segment n and n+1 overlap except in the first/last 16 bytes" is quite counterintuitive. So the "wasteful" allocations only "waste" at most 15 bytes.
- lproven 2y ago
  OK, fair enough. In hindsight I tend to think that the admittedly strong demand for flat memory, and the reduction in use of CPU protection rings, segments and so on, was taking a high-level view a huge mistake from which we have yet to recover. But yeah, from everything I read at the time, as PCs became serious tools able to run serious apps, programmers hated segments. Outside of that world, though, OSes like SCO Xenix and MWC Coherent made good use of the 286. It was actually very capable. Before that, in the early days of the 8088/8086, I think there was some value in the segment model for how it facilitated bringing across CP/M apps. When I got started in this industry, the 1980s DOS world was still dominated by modern versions of apps that originated on CP/M, which were in the late '80s just getting displaced by a new generation of much more powerful DOS apps designed for a PC with the full complement of 640kB of RAM and a hard disk. So, things like: * dBase II (CP/M) -> dBase III (PC and DOS) * WordStar 2/3 (CP/M) -> WordStar 3/4, 2000, etc. (PC and DOS) * SuperCalc (CP/M) -> SuperCalc 5 (PC and DOS) -- a late resurgence. ... were supplanted by tools like FoxPro or Clipper, WordPerfect, and Lotus 1-2-3.

csense 2y ago

1. I was using the modern definition of a processor's "bitness", i.e. the size of a memory address. (Modern x86's are considered "64-bit" even though you can use up to 512 bits at once with AVX instructions. To be fair, you're absolutely correct: These chips were assigned "bitness".) 2. I'm not super familiar with Motorola; I'll defer to you on this one. 3. Yes, I know. My point is that a modern developer used to programming in a flat address space, upon learning about segments for the first time would say "Ewww, why did they do it that way? Madness!" But if you consider the history of bank-switched systems, segments make a bit more sense. But the madness is lurking under the surface. "Why does the DOS memory allocator always give me the beginning of a segment no matter how much I allocate?" I once asked. "Isn't it incredibly wasteful to always give you 64k regardless of how many bytes you request?" Only much later did I find out that the x86 only supports 20-bit addresses and internally runs the calculation phys_address = segment*16 + offset. "Each segment is its own private 64k" was the natural (wrong) mental model I'd constructed; "segment n and n+1 overlap except in the first/last 16 bytes" is quite counterintuitive. So the "wasteful" allocations only "waste" at most 15 bytes.

lproven 2y ago
OK, fair enough. In hindsight I tend to think that the admittedly strong demand for flat memory, and the reduction in use of CPU protection rings, segments and so on, was taking a high-level view a huge mistake from which we have yet to recover. But yeah, from everything I read at the time, as PCs became serious tools able to run serious apps, programmers hated segments. Outside of that world, though, OSes like SCO Xenix and MWC Coherent made good use of the 286. It was actually very capable. Before that, in the early days of the 8088/8086, I think there was some value in the segment model for how it facilitated bringing across CP/M apps. When I got started in this industry, the 1980s DOS world was still dominated by modern versions of apps that originated on CP/M, which were in the late '80s just getting displaced by a new generation of much more powerful DOS apps designed for a PC with the full complement of 640kB of RAM and a hard disk. So, things like: * dBase II (CP/M) -> dBase III (PC and DOS) * WordStar 2/3 (CP/M) -> WordStar 3/4, 2000, etc. (PC and DOS) * SuperCalc (CP/M) -> SuperCalc 5 (PC and DOS) -- a late resurgence. ... were supplanted by tools like FoxPro or Clipper, WordPerfect, and Lotus 1-2-3.