rewriting legacy OS for new iron

[Tom Jennings]

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 <ron.hudson at sbcglobal.net> 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