The earlier DG systems (RDOS, 16-bit AOS, and some others) also had
realtime, preemptive, priority-driven multi-tasking, going back to the
'70s. I cut my teeth on those systems early in my programming career, and
never quite understood why everyone made such a big deal about "threads"
and concurrency when NT came out. We'd been doing that stuff for decades
in the DG world!
However, DG "tasks" were a bit primitive - there was only one intertask
synchronization mechanism: you could send a (16-bit) "message" to a
"mailbox", and receiver tasks could block themselves on a mailbox to await
a message. But, that's all you really need.
With 16-bit AOS (which supported multiple processes as well as multiple
tasks within a process), you had to use "IPC" (Interprocess Communication)
messages to talk across process boundries. The 16-bit AOS kernel didn't
really know about tasks - it just scheduled processes, while the task
scheduler actually ran as part of its enclosing process.
32-bit AOS/VS (and the later AOS/VS II) introduced fast(-ish) kernel
inner-ring calls which allowed you to "signal" a particular task in a
particular process, or wait for a signal, so you could avoid the rather
slow and clunky IPC mechanism to synchronize across processes.
I will leave emulation of the MV hardware, and/or re-writing AOS/VS to
others. What I would dearly love would be to find a 16-bit AOS systape
image somewhere and try to bring it up on the SIMH 16-bit Eclipse
emulator. I think Bruce Ray once mentioned that SIMH's Eclipse emulation
may not be quite complete enough to run AOS (though it runs RDOS just
fine), but that's a project I'd love to work on.
Fond memories!
...dell
On Fri, 11 May 2012, Robert G. Schaffrath wrote:
AOS/VS! That brings back memories. I used it in college back in the 1980's
on an MV/8000. Later at a reseller I worked for I had an MV/4000 in-house
and various other MV's that were in various stages of being sent to
customers. My last contact with AOS/VS would have been with release 6.0.0.0
or 7.0.0.0 in late 1987. Sadly I have forgotten a lot about it though I
still have reams of code I wrote back in the day as well as some internals
tools written in macro. I did have some fun patching the kernel to add "Load
System Ring" privilege to PID 2 as well as add an IO privilege to my profile
that PREDITOR did not offer but EXEC was more than happy to pass on to its
children.
One thing that was quite advanced for its days was support of "Tasks" which
we now call "Threads". The ability to have a program run several sections of
code simultaneously was an incredible concept though necessary in order to
implement Control-C/Control-A handlers. Cross-task synchronization and
deadlocking were all issues I learned about before they again became issues
for the "multi-threading" community.
If there ever was such an emulator I would not mind trying it out. Currently
I play with the PDP11 and VAX emulators as I would up spending much more time
working with DEC equipment than DG. As such, I have retained a lot more
knowledge about RSTS/E and VMS than I have about AOS/VS
Robert
On 5/11/2012 4:27 AM, Steve Merrony wrote:
I have heard it said that most successful OS efforts begin with with
someone who 'has an itch to scratch'. My persistent itch is a curious
desire to have AOS/VS running in some form.
Over the years there has been a small amount of discussion on this forum
about 32-bit DG, but it always peters out with someone saying they are in
touch with ex-DG IP holders and then "nothing continues to happen"...
Given the historical interest in the creation of the Eagle this seems to me
to be a crying shame.
I have been pondering a way forward; as I see it there are two options:
1. We go ahead with an MV simulator in SimH. There is a lot of intact
hardware documentation freely available on the net so I would have thought
this is technically feasible. The problem is software, but there are a few
MVs around the world now run by enthusiasts - maybe they could be
persuaded to share privately until an official solution is worked out?
2. A non-SimH route: we re-implement AOS/VS on modern hardware! The whole
OS, not just the CLI. This is clearly a wildly different option, and at
least as much work as option 1, but I think it could be a fascinating
project in its own right.
Anyone interested?
--
/Stephen Merrony
/
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
