Hacker News Reader

Hacker News

Comment by DannyB2 | Hacker News Reader

Parent Full thread

DannyB2

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.

View on HN

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.

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.

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.

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

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

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

Even with ASIDs, it's still orders of magnitude more expensive to round trip through the kernel rather than call (even far call).

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

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.

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

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)

For anybody who is curious, this is colloquially referred-to as "unreal mode": https://en.m.wikipedia.org/wiki/Unreal_mode

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.

I mean, that's just a reimplementation of segments.

You were talking about x86 segments. x86 segments overlapped. Therefore, this is not a reimplementation of the kind of segments you were talking about.

Protected mode segments are very different than real mode segments. I was talking about those.

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.

> 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

[2] DOS syscalls: http://spike.scu.edu.au/~barry/interrupts.html

[3] Source: https://en.wikibooks.org/wiki/X86_Assembly/FASM_Syntax#Hello...

[4] https://flatassembler.net/

[5] https://en.wikipedia.org/wiki/FASM

It's also how I used to code under DOS (except using int 20h to exit and save 3 bytes, plus not copying CS into DS since .com has both equal). But my point precisely is that in order to provide such small binaries, you have to 1) have the skills, and 2) accept to think. Now many devs look up for obvious responses on stackoverflow before even making the effort of solving the problem by themselves, and as a result they inherit from tons of dependencies that cannot be removed and add huge stacks of functions with absolutely zero benefit for their use case.

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

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.

Reply on news.ycombinator.com