3 ms·

We should bring back a platform like TAOS. The TAOS operating system (1991) had a virtual Instruction Set Architecture (ISA). Except for a small kernel, the en

We should bring back a platform like TAOS. The TAOS operating system (1991) had a virtual Instruction Set Architecture (ISA). Except for a small kernel, the entire OS was compiled to the virtual ISA, then assembled into actual machine code Just In Time as fast as the executable was being read off disk. This resulted in an operating system that could run with decent speeds (80-90% of native) on seemingly any hardware, which could be ported to a new platform in just 3 days. https://news.ycombinator.com/item?id=9806607 https://news.ycombinator.com/item?id=9806607

runeks 8y ago
How is this different from compiling Linux from C to LLVM to native code? And why would I ever want to generate native code for an OS at runtime?
- pjmlp 8y ago
  Not necessarily at runtime. OS/360 (IBM z nowadays) and OS/400 (IBM i nowadays) work kind of this way. The whole userspace is based on binaries deployed in a bytecode format. They are than AOT compiled into native code at installation time, or anything there are system relevant changes, via a kernel JIT service. Whole mainframe hardware migrations are possible without changing a single thing on the userspace, just doing a system refresh.
- stcredzero 8y ago
  And why would I ever want to generate native code for an OS at runtime? Why? To get write once, run everywhere. If you can do the generation at the speed the data comes off the disk, you're paying nothing for the feature. If you do things right, the abstract memory model can even be bit-identical. Even though there are differences in the underlying hardware, like endianess, all of the virtual ISAs can still implement the same virtual memory model. Smalltalk also does this, and it absolutely works across 100's of combinations of ISA and OS.
pm215 8y ago
Speaking as somebody who actually ported it (or at least the second-generation "intent/elate") to new platforms, it took more than three days (though you could probably get to "hello world" in three days or so if you were in a hurry and you only needed to handle new hardware or a new host OS, not a whole new CPU architecture).

runeks 8y ago

How is this different from compiling Linux from C to LLVM to native code? And why would I ever want to generate native code for an OS at runtime?

pjmlp 8y ago
Not necessarily at runtime. OS/360 (IBM z nowadays) and OS/400 (IBM i nowadays) work kind of this way. The whole userspace is based on binaries deployed in a bytecode format. They are than AOT compiled into native code at installation time, or anything there are system relevant changes, via a kernel JIT service. Whole mainframe hardware migrations are possible without changing a single thing on the userspace, just doing a system refresh.
stcredzero 8y ago
And why would I ever want to generate native code for an OS at runtime? Why? To get write once, run everywhere. If you can do the generation at the speed the data comes off the disk, you're paying nothing for the feature. If you do things right, the abstract memory model can even be bit-identical. Even though there are differences in the underlying hardware, like endianess, all of the virtual ISAs can still implement the same virtual memory model. Smalltalk also does this, and it absolutely works across 100's of combinations of ISA and OS.

pm215 8y ago

Speaking as somebody who actually ported it (or at least the second-generation "intent/elate") to new platforms, it took more than three days (though you could probably get to "hello world" in three days or so if you were in a hurry and you only needed to handle new hardware or a new host OS, not a whole new CPU architecture).