6 ms·

The 8086 introduced the abomination of segment registers. That created many software limitations for much of the 80's. Compilers with 64 K limits on array siz

The 8086 introduced the abomination of segment registers. That created many software limitations for much of the 80's. Compilers with 64 K limits on array sizes, or code segment sizes, and similar. By comparison the 680x0 on classic Mac was a pleasure to program. A nice large simple flat address space.

wolf550e 7y ago
Segment registers are the source of a bunch of C language rules about undefined behavior.
monocasa 7y ago
Segmentation is really nice, and should have been carried on, IMO. Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. Better segmentation support could have allowed you to sandbox memory without having to jump in and out of the kernel on transitions. Hence why VMWare, and Chrome's NaCL used segmentation hardware on x86-32 when they still could.
- adwn 7y ago
  One major issue was that the segments overlapped, so two different pointers could actually point to the same address. > Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. You don't need segments for that. A flat address space where the 2 MSBs (or however many you need) of a pointer encode the context would also work.
  - monocasa 7y ago
    I mean, that's just a reimplementation of segments.
    - adwn 7y ago
      You were talking about x86 segments. x86 segments overlapped. Therefore, this is not a reimplementation of the kind of segments you were talking about.
      - monocasa 7y ago
        Protected mode segments are very different than real mode segments. I was talking about those.
- weinzierl 7y ago
  > Segmentation is really nice, and should have been carried on, IMO. Are you serious and are you talking about x86 memory segmentation? Honest question. As far as I'm concerned thinking about CS, DS and ES still gives me shivers and I don't remember to ever have met anyone back then who loved segmentation. The only thing I hated more was the bit planes stuff on the graphics card...
  - monocasa 7y ago
    The 16-bit segments weren't great because you were forced to jump through all these hoops in order access the full addressable space. 32-bit segments that weren't crippled led to a lot of really interesting applications that weren't able to be replicated with what we have now. Hence why there's this gap of amd64 CPUs where there's no virtualization support in long mode but 32bit OSes could on the same chips.
    - weinzierl 7y ago
      Interesting, I wasn't aware that you could use them in protected mode and they were 32-bits wide from the 386 on-wards. It also reminded me of something else: I think Tanenbaum discussed the advantages of the segmented memory model in his operating systems book, but I never paid attention because coming from the 16-bit word I immediately dismissed that idea. I might have to reread that chapter...
      - Taniwha 7y ago
        It's worse than that, you can set up 32-bit segments in 32-bit mode, then switch back to 16-bit mode and have them do vaguely sensible things .... This wasn't defined by Intel, but Windows went on to depend on this feature in order to boot (to access PCI) (I was once involved in an x86 clone project)
        EvanAnderson 7y ago
        For anybody who is curious, this is colloquially referred-to as "unreal mode": https://en.m.wikipedia.org/wiki/Unreal_mode https://en.m.wikipedia.org/wiki/Unreal_mode
- jabl 7y ago
  > Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. There are ways to make page table swapping cheaper. E.g. SPARC and S390 always had separate page tables for user and kernel space, with an "ASID (address space identifier)" to avoid having to flush them when switching. I believe decently modern x86 CPU's also have this in the form of "PCID".
  - monocasa 7y ago
    Even with ASIDs, it's still orders of magnitude more expensive to round trip through the kernel rather than call (even far call).
- beagle3 7y ago
  You are describing segmentation from the 286 protected mode and later. Real mode segmentation, originally introduced in the 8086/8088, is and always was an abomination, even if you don't compare it to the elegance of the contemporary 68000/68008.
  - monocasa 7y ago
    Well, and GE-645 (ie. the special purpose MULTICS machine), the iAPX 432 (that Intel chip that gets a bad rap), the Plessey 250, and the CAP computer off the top of my head. ie. anywhere that describes the segment base, limit, and permissions on a separate privileged table.
    - tempguy9999 7y ago
      > that Intel chip that gets a bad rap I wonder why. <<<According to the New York Times, "the i432 ran 5 to 10 times more slowly than its competitor, the Motorola 68000" >>> https://en.wikipedia.org/wiki/Intel_iAPX_432#The_project%27s_failures https://en.wikipedia.org/wiki/Intel_iAPX_432#The_project%27s... From memory a quote from a user of it, something like: "on a good day it walked, on a bad day it crawled" IIRC every main memory access needed 3 pointer derefs and 3 array lookups (from memory).
wtarreau 7y ago
segment registers were a cheap MMU before its age. It was the only way to run code without relocation tables at various addresses. Mind you that at this era the whole operating system fitted in 40kB of RAM! My old turbo-pascal 3.0 editor+compiler was something around 37 kB! Just try to write a hello world of that size nowadays! It's pointless to criticize the past based on 10000 times more powerful hardware nowadays, which doesn't even deliver the same work faster due to the tremendous waste of resource caused by laziness and incompetence.
- winter_blue 7y ago
  > Just try to write a hello world of that size nowadays! The only reason why hello world binaries are bloated is because compilers for several compiled-to-native languages statically link many standard library functions into the final output executable. You can write a hello world DOS terminal program[1] for x86, using the DOS syscall 9 (invoked with interrupt 21h)[2]: format MZ push cs pop ds mov ah,9 mov dx,hello int 21h mov ax,4C00h int 21h hello db 'Hello world!',24h This would compile down to a handful of bytes. Alternatively, if you want to use modern Windows syscalls (instead of legacy DOS syscalls), you can dynamically link to the Windows system libraries, and implement the hello world like so[3]: format PE console ; Win32 portable executable console format entry _start ; _start is the program's entry point include 'INCLUDE/WIN32A.INC' section '.data' data readable writable ; data definitions hello db "Hello World!", 0 stringformat db "%s", 0ah, 0 section '.code' code readable executable ; code _start: invoke printf, stringformat, hello ; call printf, defined in msvcrt.dll invoke getchar ; wait for any key invoke ExitProcess, 0 ; exit the process section '.imports' import data readable ; data imports library kernel, 'kernel32.dll',\ ; link to kernel32.dll, msvcrt.dll msvcrt, 'msvcrt.dll' import kernel, \ ; import ExitProcess from kernel32.dll ExitProcess, 'ExitProcess' import msvcrt, \ ; import printf and getchar from msvcrt.dll printf, 'printf',\ getchar, '_fgetchar' This too would likely be under a kilobyte. All of this uses fasm (flat assembler)[4][5]. [1] Source: https://board.flatassembler.net/topic.php?t=1736 https://board.flatassembler.net/topic.php?t=1736 [2] DOS syscalls: http://spike.scu.edu.au/~barry/interrupts.html http://spike.scu.edu.au/~barry/interrupts.html [3] Source: https://en.wikibooks.org/wiki/X86_Assembly/FASM_Syntax#Hello_World https://en.wikibooks.org/wiki/X86_Assembly/FASM_Syntax#Hello... [4] https://flatassembler.net/ https://flatassembler.net/ [5] https://en.wikipedia.org/wiki/FASM https://en.wikipedia.org/wiki/FASM
upofadown 7y ago
Yeah, as I said, the 8086 was a pretty good 16 bit processor. It might not of been such a great 20 bit processor (it could only address 1 MB even with the segmentation). >By comparison the 680x0 on classic Mac was a pleasure to program. A nice large simple flat address space. That was a 32 bit processor. Yes things are simpler for large programs when you have lots of memory to put your code in and your instructions can take lots of space. The 68000 was as a result a lot easier to design. It was basically just a PDP-11 clone.

wolf550e 7y ago

Segment registers are the source of a bunch of C language rules about undefined behavior.

monocasa 7y ago

Segmentation is really nice, and should have been carried on, IMO. Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. Better segmentation support could have allowed you to sandbox memory without having to jump in and out of the kernel on transitions. Hence why VMWare, and Chrome's NaCL used segmentation hardware on x86-32 when they still could.

adwn 7y ago
One major issue was that the segments overlapped, so two different pointers could actually point to the same address. > Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. You don't need segments for that. A flat address space where the 2 MSBs (or however many you need) of a pointer encode the context would also work.
- monocasa 7y ago
  I mean, that's just a reimplementation of segments.
  - adwn 7y ago
    You were talking about x86 segments. x86 segments overlapped. Therefore, this is not a reimplementation of the kind of segments you were talking about.
    - monocasa 7y ago
      Protected mode segments are very different than real mode segments. I was talking about those.
weinzierl 7y ago
> Segmentation is really nice, and should have been carried on, IMO. Are you serious and are you talking about x86 memory segmentation? Honest question. As far as I'm concerned thinking about CS, DS and ES still gives me shivers and I don't remember to ever have met anyone back then who loved segmentation. The only thing I hated more was the bit planes stuff on the graphics card...
- monocasa 7y ago
  The 16-bit segments weren't great because you were forced to jump through all these hoops in order access the full addressable space. 32-bit segments that weren't crippled led to a lot of really interesting applications that weren't able to be replicated with what we have now. Hence why there's this gap of amd64 CPUs where there's no virtualization support in long mode but 32bit OSes could on the same chips.
  - weinzierl 7y ago
    Interesting, I wasn't aware that you could use them in protected mode and they were 32-bits wide from the 386 on-wards. It also reminded me of something else: I think Tanenbaum discussed the advantages of the segmented memory model in his operating systems book, but I never paid attention because coming from the 16-bit word I immediately dismissed that idea. I might have to reread that chapter...
    - Taniwha 7y ago
      It's worse than that, you can set up 32-bit segments in 32-bit mode, then switch back to 16-bit mode and have them do vaguely sensible things .... This wasn't defined by Intel, but Windows went on to depend on this feature in order to boot (to access PCI) (I was once involved in an x86 clone project)
      - EvanAnderson 7y ago
        For anybody who is curious, this is colloquially referred-to as "unreal mode": https://en.m.wikipedia.org/wiki/Unreal_mode https://en.m.wikipedia.org/wiki/Unreal_mode
jabl 7y ago
> Half the issue with Spectre is that there isn't a clean way to describe to the processor different memory security contexts except with a page table pointer swap. There are ways to make page table swapping cheaper. E.g. SPARC and S390 always had separate page tables for user and kernel space, with an "ASID (address space identifier)" to avoid having to flush them when switching. I believe decently modern x86 CPU's also have this in the form of "PCID".
- monocasa 7y ago
  Even with ASIDs, it's still orders of magnitude more expensive to round trip through the kernel rather than call (even far call).
beagle3 7y ago
You are describing segmentation from the 286 protected mode and later. Real mode segmentation, originally introduced in the 8086/8088, is and always was an abomination, even if you don't compare it to the elegance of the contemporary 68000/68008.
- monocasa 7y ago
  Well, and GE-645 (ie. the special purpose MULTICS machine), the iAPX 432 (that Intel chip that gets a bad rap), the Plessey 250, and the CAP computer off the top of my head. ie. anywhere that describes the segment base, limit, and permissions on a separate privileged table.
  - tempguy9999 7y ago
    > that Intel chip that gets a bad rap I wonder why. <<<According to the New York Times, "the i432 ran 5 to 10 times more slowly than its competitor, the Motorola 68000" >>> https://en.wikipedia.org/wiki/Intel_iAPX_432#The_project%27s_failures https://en.wikipedia.org/wiki/Intel_iAPX_432#The_project%27s... From memory a quote from a user of it, something like: "on a good day it walked, on a bad day it crawled" IIRC every main memory access needed 3 pointer derefs and 3 array lookups (from memory).

wtarreau 7y ago

segment registers were a cheap MMU before its age. It was the only way to run code without relocation tables at various addresses. Mind you that at this era the whole operating system fitted in 40kB of RAM! My old turbo-pascal 3.0 editor+compiler was something around 37 kB! Just try to write a hello world of that size nowadays! It's pointless to criticize the past based on 10000 times more powerful hardware nowadays, which doesn't even deliver the same work faster due to the tremendous waste of resource caused by laziness and incompetence.

winter_blue 7y ago
> Just try to write a hello world of that size nowadays! The only reason why hello world binaries are bloated is because compilers for several compiled-to-native languages statically link many standard library functions into the final output executable. You can write a hello world DOS terminal program[1] for x86, using the DOS syscall 9 (invoked with interrupt 21h)[2]: format MZ push cs pop ds mov ah,9 mov dx,hello int 21h mov ax,4C00h int 21h hello db 'Hello world!',24h This would compile down to a handful of bytes. Alternatively, if you want to use modern Windows syscalls (instead of legacy DOS syscalls), you can dynamically link to the Windows system libraries, and implement the hello world like so[3]: format PE console ; Win32 portable executable console format entry _start ; _start is the program's entry point include 'INCLUDE/WIN32A.INC' section '.data' data readable writable ; data definitions hello db "Hello World!", 0 stringformat db "%s", 0ah, 0 section '.code' code readable executable ; code _start: invoke printf, stringformat, hello ; call printf, defined in msvcrt.dll invoke getchar ; wait for any key invoke ExitProcess, 0 ; exit the process section '.imports' import data readable ; data imports library kernel, 'kernel32.dll',\ ; link to kernel32.dll, msvcrt.dll msvcrt, 'msvcrt.dll' import kernel, \ ; import ExitProcess from kernel32.dll ExitProcess, 'ExitProcess' import msvcrt, \ ; import printf and getchar from msvcrt.dll printf, 'printf',\ getchar, '_fgetchar' This too would likely be under a kilobyte. All of this uses fasm (flat assembler)[4][5]. [1] Source: https://board.flatassembler.net/topic.php?t=1736 https://board.flatassembler.net/topic.php?t=1736 [2] DOS syscalls: http://spike.scu.edu.au/~barry/interrupts.html http://spike.scu.edu.au/~barry/interrupts.html [3] Source: https://en.wikibooks.org/wiki/X86_Assembly/FASM_Syntax#Hello_World https://en.wikibooks.org/wiki/X86_Assembly/FASM_Syntax#Hello... [4] https://flatassembler.net/ https://flatassembler.net/ [5] https://en.wikipedia.org/wiki/FASM https://en.wikipedia.org/wiki/FASM

upofadown 7y ago

Yeah, as I said, the 8086 was a pretty good 16 bit processor. It might not of been such a great 20 bit processor (it could only address 1 MB even with the segmentation). >By comparison the 680x0 on classic Mac was a pleasure to program. A nice large simple flat address space. That was a 32 bit processor. Yes things are simpler for large programs when you have lots of memory to put your code in and your instructions can take lots of space. The 68000 was as a result a lot easier to design. It was basically just a PDP-11 clone.