rewriting legacy OS for new iron

From: Tom Jennings <>
Date: Wed Sep 15 16:08:54 2004

Isn't this sort of task better handled by a CPU-instruction-set-type
simulator? Sheesh, with the CPUs we have today you could code it up in
Perl and get good performance.

Hardware interface though would be a Really Big Deal. You could always
Punt and when you get to a read-disk-block OS call, palm it off on the
host OS.

This approach isn't new, it's as old as stored-program computing.

On Tue, 2004-09-14 at 07:17, Paul Koning wrote:
> >>>>> "Ron" == Ron Hudson <> writes:
> Ron> Would there be any interest in re-writing somthing like RSTS/E,
> Ron> ITS, TWENEX or one of the other legacy OS to work on x86
> Ron> machines? The idea would be to do something like Linux has done
> Ron> for unix but for one of the other OSs, I think all the ones I
> Ron> mentioned ran on pdp machines, whatever we choose to write could
> Ron> have once run on anything.
> What would it mean to "run" such an OS on an x86? Consider RSTS,
> which is the only one of those three I know well. The OS itself is
> 100% assembly language. The system services are defined in terms of
> request blocks in low user memory along with system call instructions
> (EMT opcode of the PDP-11). Applications were generally written in
> Basic-Plus (or -2), or in PDP11 assembler; rarely in some other
> language such as TECO, or FORTH, or others.
> I could imagine creating a Basic-Plus environment that emulates that
> aspect of RSTS. I could also imagine a BP2 compiler that generates
> X86 code. The surrounding machinery -- "run time systems", the system
> service semantics, etc. -- that would be tricky. Assuming you get
> that far, you have a user mode analog of the original, so old
> applications (if written in Basic-Plus or BP2) would run. The same
> would go for TECO. Assembly language applications have no chance
> short of running an emulator at least for user mode. The same goes
> for FORTH, since it tends to hook right into the assembly style system
> service API, though obviously you could replace just that small part
> and keep the rest.
> paul
Received on Wed Sep 15 2004 - 16:08:54 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:29 BST