3 ms·

I think the idea of the segment registers is to create isolated memory ranges for multi tasking. These segments are at the granularity of 16 bytes and have a st

by pkaye 6y ago

I think the idea of the segment registers is to create isolated memory ranges for multi tasking. These segments are at the granularity of 16 bytes and have a starting offset and length within 1MB of RAM. There are multiple segments so the code segment can be shared between processes and have separate stack and data segments. When you imagine it as one big 1MB address space this memory model looks wierd.

andrewf 6y ago
Intel leaned into this with the 286's protected mode - segments became references to "selectors" so the OS could place your 64k chunks of code/data wherever it wanted within 16M. I think the existing base of 8080 software (including CP/M software) was on their minds. You see the same thing in the 386/486, they have the large flat virtual address space software devs wanted, but until the early 90s their commercial value was running 8088 software really fast.
- pwg 6y ago
  >I think the existing base of 8080 software (including CP/M software) was on their minds. This is the generally accepted history. According to what's in Wikipedia (https://en.wikipedia.org/wiki/Intel_8086#The_first_x86_design https://en.wikipedia.org/wiki/Intel_8086#The_first_x86_desig...) the design was developed very quickly, and intentionally built as a straightforward 'extension' of the 8080/8085 chips into the 16-bit world: -quote- The first x86 design The 8086 project started in May 1976 and was originally intended as a temporary substitute for the ambitious and delayed iAPX 432 project. ... Both the architecture and the physical chip were therefore developed rather quickly by a small group of people, and using the same basic microarchitecture elements and physical implementation techniques as employed for the slightly older 8085 (and for which the 8086 also would function as a continuation). Marketed as source compatible, the 8086 was designed to allow assembly language for the 8008, 8080, or 8085 to be automatically converted into equivalent (suboptimal) 8086 source code, with little or no hand-editing. The programming model and instruction set is (loosely) based on the 8080 in order to make this possible. However, the 8086 design was expanded to support full 16-bit processing, instead of the fairly limited 16-bit capabilities of the 8080 and 8085. -end quote-
kiwidrew 6y ago
What the segment registers actually allowed was a primitive form of relocatable code: the 8086 didn't have PC-relative addressing modes, so instead what you got was 16-bit absolute addressing that was segment-relative. DOS could load .COM files (which had a 64KB limit and used the "tiny" model where all the segment registers point to the same 64KB region of memory) at any offset in conventional memory without needing to perform any runtime relocation. Combined with the lack of any header this made perfect sense for small utilities that needed to execute quickly.
- hyperman1 6y ago
  I've never bothered to check this, but recently I was told that COM files could be >64K. The DOS loader would just keep loading data until the real 640K end of memory was reached. The program itself would be responsible to modify segment register to gain access to the unreachable parts of itself. It seems technologically possible, as a program could always assume memory above its own segment (up to A000 of course) was free. Can anyone conform or deny?
  - jart 6y ago
    I can't speak for DOS support but I love building COM binaries on Linux which exceed 64k thanks to SFX which allows us to respect the GPL with source code bundling. https://raw.githubusercontent.com/jart/cosmopolitan/master/ape/ape.S https://raw.githubusercontent.com/jart/cosmopolitan/master/a...

by pkaye 6y ago

andrewf 6y ago

Intel leaned into this with the 286's protected mode - segments became references to "selectors" so the OS could place your 64k chunks of code/data wherever it wanted within 16M. I think the existing base of 8080 software (including CP/M software) was on their minds. You see the same thing in the 386/486, they have the large flat virtual address space software devs wanted, but until the early 90s their commercial value was running 8088 software really fast.

pwg 6y ago
>I think the existing base of 8080 software (including CP/M software) was on their minds. This is the generally accepted history. According to what's in Wikipedia (https://en.wikipedia.org/wiki/Intel_8086#The_first_x86_design https://en.wikipedia.org/wiki/Intel_8086#The_first_x86_desig...) the design was developed very quickly, and intentionally built as a straightforward 'extension' of the 8080/8085 chips into the 16-bit world: -quote- The first x86 design The 8086 project started in May 1976 and was originally intended as a temporary substitute for the ambitious and delayed iAPX 432 project. ... Both the architecture and the physical chip were therefore developed rather quickly by a small group of people, and using the same basic microarchitecture elements and physical implementation techniques as employed for the slightly older 8085 (and for which the 8086 also would function as a continuation). Marketed as source compatible, the 8086 was designed to allow assembly language for the 8008, 8080, or 8085 to be automatically converted into equivalent (suboptimal) 8086 source code, with little or no hand-editing. The programming model and instruction set is (loosely) based on the 8080 in order to make this possible. However, the 8086 design was expanded to support full 16-bit processing, instead of the fairly limited 16-bit capabilities of the 8080 and 8085. -end quote-

kiwidrew 6y ago

What the segment registers actually allowed was a primitive form of relocatable code: the 8086 didn't have PC-relative addressing modes, so instead what you got was 16-bit absolute addressing that was segment-relative. DOS could load .COM files (which had a 64KB limit and used the "tiny" model where all the segment registers point to the same 64KB region of memory) at any offset in conventional memory without needing to perform any runtime relocation. Combined with the lack of any header this made perfect sense for small utilities that needed to execute quickly.

hyperman1 6y ago
I've never bothered to check this, but recently I was told that COM files could be >64K. The DOS loader would just keep loading data until the real 640K end of memory was reached. The program itself would be responsible to modify segment register to gain access to the unreachable parts of itself. It seems technologically possible, as a program could always assume memory above its own segment (up to A000 of course) was free. Can anyone conform or deny?
- jart 6y ago
  I can't speak for DOS support but I love building COM binaries on Linux which exceed 64k thanks to SFX which allows us to respect the GPL with source code bundling. https://raw.githubusercontent.com/jart/cosmopolitan/master/ape/ape.S https://raw.githubusercontent.com/jart/cosmopolitan/master/a...