15 Sep
2004
15 Sep
'04
9:08 a.m.
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(a)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