6 ms·

Has anyone attempted to port these pre-Unix oses to modern hardware?

klyrs 6y ago
I found some here https://www.inwap.com/pdp10/emulators/ https://www.inwap.com/pdp10/emulators/ > This is the 5,376th access to this page. Hope we don't hug it too hard
- fiddlerwoaroof 6y ago
  I know about emulators, but I’d think someone would have found porting ITS or Multics to x86 or Arm a fun hobby project
  - unused0 6y ago
    Multics was co-developed with the hardware; that hardware contains Multics specific features that are needed to implement Multics. Segment tables, Rings, Gates and more. enable the memory mapping and protection that that is the basis of Multics. These hardware features are not found in the current gamut of architectures due to the dominance of the marketing value of being the fasted CPU; these features lower the CPU throughput and also cost valuable silicon space, and the economic value of a secure OS is less then the value of being faster or shinier.
    - Jkvngt 6y ago
      Here's hoping that state level and non state actors make a huge mess of everything we have now so everybody can sit in the corner and have a big think.
      - sbierwagen 6y ago
        I'm not sure about that? Chip-level security functions forcing cache flushes seem like they would be ripe for Meltdown/Spectre-style attacks.
    - gpderetta 6y ago
      Being fast is hardly a marketing feature. X86 had gates, segment tables and rings (still fully functional in 32 bit mode, so having them is not an hindrance on being fast). They got dropped in 64 bit mode because no software has used them in 25 years.
      - corty 6y ago
        Having them wasn't a hindrance, luckily for intel. But using them to the full extent was far slower than not. E.g. call gates as a syscall mechanism have a far higher overhead compared to int80. Segments, when used in the intended finer-than-page granularity are also too slow, because changing a segment register often is very costly in terms of cache and TLB flush. That's why everyone just used a few fixed segments that almost never changed and did the interesting stuff with page-based memory management.
      - rbanffy 6y ago
        > They got dropped in 64 bit mode because no software has used them in 25 years. I think there was one that used them, but i can't remember its name. Maybe someone here can help. It was obscure enough that Intel didn't think too much about removing them.
        gpderetta 6y ago
        IIRC Segments were used to speed up (para?) virtualization, before built-in support in the ISA. Segment registers are also used as thread pointer, but that special case is still supported even in 64 bit mode.
        rbanffy 6y ago
        I was talking about the rings. I remember something that used them.
        gpderetta 6y ago
        I think NT at some point run drvers and some other subsystems in lesser privileged rings than ring 0. Not sure if this was dropped in later versions.
gumby 6y ago
Remember ITS was written in assembly language for the PDP-10, a 36-bit machine with an 18-bit address space (yes, it was also intended to run Lisp efficiently). It was a fun machine to program in assembly code, emulatable on a 64-bit machine sure. But not something you would "port" to a different architecture.
- musicale 6y ago
  I bet you could write a translator to convert PDP-10 code to x86 code or something. You could also probably rewrite it manually.

I found some here https://www.inwap.com/pdp10/emulators/ https://www.inwap.com/pdp10/emulators/ > This is the 5,376th access to this page. Hope we don't hug it too hard

fiddlerwoaroof 6y ago
I know about emulators, but I’d think someone would have found porting ITS or Multics to x86 or Arm a fun hobby project
- unused0 6y ago
  Multics was co-developed with the hardware; that hardware contains Multics specific features that are needed to implement Multics. Segment tables, Rings, Gates and more. enable the memory mapping and protection that that is the basis of Multics. These hardware features are not found in the current gamut of architectures due to the dominance of the marketing value of being the fasted CPU; these features lower the CPU throughput and also cost valuable silicon space, and the economic value of a secure OS is less then the value of being faster or shinier.
  - Jkvngt 6y ago
    Here's hoping that state level and non state actors make a huge mess of everything we have now so everybody can sit in the corner and have a big think.
    - sbierwagen 6y ago
      I'm not sure about that? Chip-level security functions forcing cache flushes seem like they would be ripe for Meltdown/Spectre-style attacks.
  - gpderetta 6y ago
    Being fast is hardly a marketing feature. X86 had gates, segment tables and rings (still fully functional in 32 bit mode, so having them is not an hindrance on being fast). They got dropped in 64 bit mode because no software has used them in 25 years.
    - corty 6y ago
      Having them wasn't a hindrance, luckily for intel. But using them to the full extent was far slower than not. E.g. call gates as a syscall mechanism have a far higher overhead compared to int80. Segments, when used in the intended finer-than-page granularity are also too slow, because changing a segment register often is very costly in terms of cache and TLB flush. That's why everyone just used a few fixed segments that almost never changed and did the interesting stuff with page-based memory management.
    - rbanffy 6y ago
      > They got dropped in 64 bit mode because no software has used them in 25 years. I think there was one that used them, but i can't remember its name. Maybe someone here can help. It was obscure enough that Intel didn't think too much about removing them.
      - gpderetta 6y ago
        IIRC Segments were used to speed up (para?) virtualization, before built-in support in the ISA. Segment registers are also used as thread pointer, but that special case is still supported even in 64 bit mode.
        rbanffy 6y ago
        I was talking about the rings. I remember something that used them.
        gpderetta 6y ago
        I think NT at some point run drvers and some other subsystems in lesser privileged rings than ring 0. Not sure if this was dropped in later versions.

gumby 6y ago

Remember ITS was written in assembly language for the PDP-10, a 36-bit machine with an 18-bit address space (yes, it was also intended to run Lisp efficiently). It was a fun machine to program in assembly code, emulatable on a 64-bit machine sure. But not something you would "port" to a different architecture.

musicale 6y ago
I bet you could write a translator to convert PDP-10 code to x86 code or something. You could also probably rewrite it manually.