7 ms·

>... a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In fairness to the Intel of that era, they actually did a really g

>... a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In fairness to the Intel of that era, they actually did a really good job with this. They gained basically zero warts from the 8080 assembler source compatibility. They mostly set out to make the best variable length 16 bit instruction set they could. They had significant competition at the time and they pretty much had to make the 8086 instruction set something very usable. The x86 instruction set horror mostly came after that.

kjs3 7y ago
Linus has some thoughts on this: https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html
DannyB2 7y ago
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.
- 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.
snvzz 7y ago
z80 and 8086 were both garbage, next to the 68000. It's sad x86 survived this far and is still so popular. Hopefully RISC-V will put an end to this hell.
- wolfgke 7y ago
  > z80 and 8086 were both garbage, next to the 68000. At that time, Z80 and 8088/8086 targeted very different market segments than the 68000. So, this is a quite unfair comparison.
  - AnimalMuppet 7y ago
    OK, the 286 was also garbage compared to the 68000.
    - kjs3 7y ago
      I know it's heretical, but the '286 had a bunch of really interesting innovations, like a primitive capabilities based architecture. The big downfall of the '286 was they tried to do the 8086 backward compatibility and completely screwed it up. Ignoring that and writing an OS just for the '286 features was kinda interesting at the time. Not now...but at the time.
    - tropo 7y ago
      The 68000 has some serious design flaws in the architecture. A notable one is the autoincrement and autodecrement of indirect memory references. This makes it difficult to get the architecture running instructions in parallel. Memory can be changing, but the address at which it changes is determined late. It gets even more troublesome if the CPU comes with a MMU. It becomes necessary to avoid actually performing the autoincrement or autodecrement until all page faults have been resolved. (getting that VAX feel here) Remember that memory accesses can go to the same location as other memory accesses and/or to memory mapped IO, so simply rolling back the value is no good. The situation with flags wasn't any better than x86 has, which is pretty bad. There are partial flags updates, undefined flag updates, and a mix of math flags with other types of flags. The interrupt situation was bad. The CPU architecture specifies a small number of levels. Better designs, like x86 and PowerPC, leave that up to the interrupt controller chipset.

kjs3 7y ago

Linus has some thoughts on this: https://yarchive.net/comp/linux/x86.html https://yarchive.net/comp/linux/x86.html

DannyB2 7y ago

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

snvzz 7y ago

z80 and 8086 were both garbage, next to the 68000. It's sad x86 survived this far and is still so popular. Hopefully RISC-V will put an end to this hell.

wolfgke 7y ago
> z80 and 8086 were both garbage, next to the 68000. At that time, Z80 and 8088/8086 targeted very different market segments than the 68000. So, this is a quite unfair comparison.
- AnimalMuppet 7y ago
  OK, the 286 was also garbage compared to the 68000.
  - kjs3 7y ago
    I know it's heretical, but the '286 had a bunch of really interesting innovations, like a primitive capabilities based architecture. The big downfall of the '286 was they tried to do the 8086 backward compatibility and completely screwed it up. Ignoring that and writing an OS just for the '286 features was kinda interesting at the time. Not now...but at the time.
  - tropo 7y ago
    The 68000 has some serious design flaws in the architecture. A notable one is the autoincrement and autodecrement of indirect memory references. This makes it difficult to get the architecture running instructions in parallel. Memory can be changing, but the address at which it changes is determined late. It gets even more troublesome if the CPU comes with a MMU. It becomes necessary to avoid actually performing the autoincrement or autodecrement until all page faults have been resolved. (getting that VAX feel here) Remember that memory accesses can go to the same location as other memory accesses and/or to memory mapped IO, so simply rolling back the value is no good. The situation with flags wasn't any better than x86 has, which is pretty bad. There are partial flags updates, undefined flag updates, and a mix of math flags with other types of flags. The interrupt situation was bad. The CPU architecture specifies a small number of levels. Better designs, like x86 and PowerPC, leave that up to the interrupt controller chipset.