4 ms·

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

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

by csense 2y ago

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.