4 ms·

It's a little awful to think about just how much collective human effort was wasted by segmented memory. Everyone knew that 32-bit flat memory was the future; i

It's a little awful to think about just how much collective human effort was wasted by segmented memory. Everyone knew that 32-bit flat memory was the future; it just took a long time for the PC platform to get there.

jandrese 2y ago
Yeah, but when you are shipping computers with 256kb like the original PC/XT those extra two bytes per pointer start to look like a major luxury. There was a heroic amount of effort in those days to make due with as little memory as possible because memory was so expensive that nobody had more than was absolutely necessary.
- ghaff 2y ago
  Yeah. I’m not going to defend x86 segment registers and real-mode DOS too vigorously. (I programmed in x86 assembler for many years.) But I’m pretty sure the right approach wasn’t to say Screw it. Let’s wait until a 32-bit flat address space processor and OS come along at the consumer and individual business user level.
- jojobas 2y ago
  Segment:offset addresses were still 32 bits right? And most of the arseache was from the fact that the segments were overlapping as I understand.
  - skissane 2y ago
    Yes, but if your program required no more than 64KB of data, then you could use near pointers everywhere, halving the pointer size from 4 bytes to 2 bytes. Also, even if the program as a whole required more than 64KB of data, if you knew you required no more than 64KB of data for objects of type X, then you could use 2 byte pointers for all type X objects, with a fixed data segment. X here might, for example, be strings. When you only have 256KB of RAM to begin with, the odds that all data overall, or at least all X object data for some X, will fit in 64KB is quite high. And if you have a lot of pointers, halving their size makes a big difference when you have so little memory.
    - MagerValp 2y ago
      But segmented memory isn’t a requirement, that technique works just as well with linear address space. You use a single 32-bit base pointer and then store 16-bit offsets for your data. We used that all the time on 68K and other architectures.
      - skissane 2y ago
        The difference is that 68K is designed as fundamentally a 32-bit architecture. (Even though the original implementation was physically 16-bit.) Whereas 8086 is a 16-bit architecture with an extended address space. The use of segmentation to enable a 16-bit architecture to address more than 64K was not original to the 8086, many 16-bit minicomputers (e.g. the PDP-11) used the same basic idea, although the specific implementation Intel chose was rather unique Part of why the 8086 was 16-bit not 32-bit, was to make it easier to port software to it from the 8080, which was an 8-bit architecture with 16-bit addressing. It also was likely one of the reasons why the 8086/8088 was cheaper than the 68K, which is part of why IBM chose it over the 68K for the IBM PC
        p_l 2y ago
        I heard opinions that 8086 won for IBM PC project because it was available for longer and more proven, with more options for second-sourcing.
        actionfromafar 2y ago
        That would be fact - AMD was the second source for the 8088. (Licensing IP from Intel.)
        p_l 2y ago
        Motorola 68000 also had second sourcing options, just like 8088 - but 8086 was released a year earlier and built up on well-known successful design of 8080, even if they weren't exactly compatible. It built confidence about Intel's ability to deliver, even when 8088 was released the same year as 68k, as it was just bus-narrowed cheaper version, not an entire architecture.
skissane 2y ago
I think it was unfortunate Intel went with 16 byte paragraphs instead of 256 byte. With 256 byte paragraphs, you would have been able to address 16MB instead of 1MB in real mode.
- iforgotpassword 2y ago
  Why not just the full 64k. The sliding window trick was of such limited use compared to the headaches it caused. Or maybe 32k as a compromise. But then they repeated the same mistake with the 286, again!
  - skissane 2y ago
    > Why not just the full 64k. The sliding window trick was of such limited use compared to the headaches it caused. As I pointed out in my other comment, the full 64KB would have made it harder to support child processes under DOS. Suppose I have 300KB of free conventional memory, and run an 8KB program (something like a menu program, for example.) If it starts a child process, that child process has about 292KB of free conventional memory to use. With your idea, it could only have 236KB, because even though the parent process only needs 8KB of memory, it would consume a whole 64KB.

jandrese 2y ago

Yeah, but when you are shipping computers with 256kb like the original PC/XT those extra two bytes per pointer start to look like a major luxury. There was a heroic amount of effort in those days to make due with as little memory as possible because memory was so expensive that nobody had more than was absolutely necessary.

ghaff 2y ago
Yeah. I’m not going to defend x86 segment registers and real-mode DOS too vigorously. (I programmed in x86 assembler for many years.) But I’m pretty sure the right approach wasn’t to say Screw it. Let’s wait until a 32-bit flat address space processor and OS come along at the consumer and individual business user level.
jojobas 2y ago
Segment:offset addresses were still 32 bits right? And most of the arseache was from the fact that the segments were overlapping as I understand.
- skissane 2y ago
  Yes, but if your program required no more than 64KB of data, then you could use near pointers everywhere, halving the pointer size from 4 bytes to 2 bytes. Also, even if the program as a whole required more than 64KB of data, if you knew you required no more than 64KB of data for objects of type X, then you could use 2 byte pointers for all type X objects, with a fixed data segment. X here might, for example, be strings. When you only have 256KB of RAM to begin with, the odds that all data overall, or at least all X object data for some X, will fit in 64KB is quite high. And if you have a lot of pointers, halving their size makes a big difference when you have so little memory.
  - MagerValp 2y ago
    But segmented memory isn’t a requirement, that technique works just as well with linear address space. You use a single 32-bit base pointer and then store 16-bit offsets for your data. We used that all the time on 68K and other architectures.
    - skissane 2y ago
      The difference is that 68K is designed as fundamentally a 32-bit architecture. (Even though the original implementation was physically 16-bit.) Whereas 8086 is a 16-bit architecture with an extended address space. The use of segmentation to enable a 16-bit architecture to address more than 64K was not original to the 8086, many 16-bit minicomputers (e.g. the PDP-11) used the same basic idea, although the specific implementation Intel chose was rather unique Part of why the 8086 was 16-bit not 32-bit, was to make it easier to port software to it from the 8080, which was an 8-bit architecture with 16-bit addressing. It also was likely one of the reasons why the 8086/8088 was cheaper than the 68K, which is part of why IBM chose it over the 68K for the IBM PC
      - p_l 2y ago
        I heard opinions that 8086 won for IBM PC project because it was available for longer and more proven, with more options for second-sourcing.
        actionfromafar 2y ago
        That would be fact - AMD was the second source for the 8088. (Licensing IP from Intel.)
        p_l 2y ago
        Motorola 68000 also had second sourcing options, just like 8088 - but 8086 was released a year earlier and built up on well-known successful design of 8080, even if they weren't exactly compatible. It built confidence about Intel's ability to deliver, even when 8088 was released the same year as 68k, as it was just bus-narrowed cheaper version, not an entire architecture.

skissane 2y ago

I think it was unfortunate Intel went with 16 byte paragraphs instead of 256 byte. With 256 byte paragraphs, you would have been able to address 16MB instead of 1MB in real mode.

iforgotpassword 2y ago
Why not just the full 64k. The sliding window trick was of such limited use compared to the headaches it caused. Or maybe 32k as a compromise. But then they repeated the same mistake with the 286, again!
- skissane 2y ago
  > Why not just the full 64k. The sliding window trick was of such limited use compared to the headaches it caused. As I pointed out in my other comment, the full 64KB would have made it harder to support child processes under DOS. Suppose I have 300KB of free conventional memory, and run an 8KB program (something like a menu program, for example.) If it starts a child process, that child process has about 292KB of free conventional memory to use. With your idea, it could only have 236KB, because even though the parent process only needs 8KB of memory, it would consume a whole 64KB.