[Simh] RSX-20F

[Johnny Billquist]

On 2015-03-19 23:27, Timothe Litt wrote:
>
>> I've definitely been using RSX-20F on a KL-10 myself a few times. On
>> our machine it certainly did not take anything close to a minute to
>> get the command parser. It took a couple of seconds.
>> Did you run on a DECtape based system or something? Actually, since it
>> booted of the RP06 anyway, the console storage should matter even less.
>>
> Timing depended on what all was going on.  DECtapes were slow.  Floppy
> seemed faster, but still very slow.  The RP06, being dual ported with
> the -10 could take a while to acquire.  -20F did small I/Os, had no disk
> cache and didn't worry much about caching ACP data.  All that was
> secondary.  Running the peripherals was its real-time job.  Everything
> else was secondary, and heavily overlaid to fit.  Plus, usually GEN
> wasn't empty, and loading the parser wasn't preemptive.  Something else
> had to finish and be kicked-out.
>
> Yes, on an idle system running from disk it could be a few seconds
> (though I don't think as few as 2).  On a busy system, a minute wasn't
> unrealistic.

Ok. Well, when I did play on the FE, the PDP-10 was not serving users, 
so that might explain it.

>> Yes, you could only run one thing at the time. That's a pretty normal
>> effect from running on an unmapped system. In addition to there not
>> being much memory, all tasks also have to be task built (linked) to
>> physical addresses. You do not have virtual memory on the RSX-20F system.
>> And all programs are task built to run in the same memory partition,
>> so it's pretty much impossible to run two programs at the same time in
>> the common sense of the word. F11ACP is an example of a separate
>> program that runs at the same time as your command. But F11ACP runs in
>> a different partition. And there are a few other tasks that are task
>> built to run in that partition as well, so F11ACP can also be forced
>> out of memory.
>>
> I know all that.  I wrote device drivers and random applications under
> 11M V2, V3.something on 11/20s long before suffering with -20F.
>
> I tracked down anti-social behavior in F11ACP - a truly miserable piece
> of code that took modular programming to an extreme.  I know all too
> well how it worked.  Zillions of files that had 3 pages of copyrights &
> docs, a label, a set carry instruction and a return.  File pointer
> windows that were cached in the UCB to do VBN to LBN translation.
>
> Many un-mapped systems had (and have) loaders capable of relocating
> tasks when activated.  You see some of that today on Unix, when a
> sharable library is loaded.  VMS could deal with that as well.  In an
> unmapped system, the big issue was fragmentation as tasks load and
> unload.  Partitions were a cheap way of pushing that back on the programmer.

All true. Except I don't think VMS actually do relocation at load time. 
The VAX instruction set was capable enough that pretty much all code you 
ever wrote was already PIC. The only things to resolve were external 
symbols, but I don't think VMS allowed shareable images to refer to 
external, unresolved symbols to start with. But I might be wrong on that.

> Partitions were also a way of avoiding runtime relocation overhead - an
> idea (and a term) copied from older machines.  A design trade-off, but
> not the only way.  But IIRC later version of 11M allowed multiple tasks
> in the GEN partition.  I'm not sure if that was supported without memory
> management.  There's no technical reason it couldn't have been, with
> enough work.  I left 11M behind around that time.

All versions of RSX allows multiple tasks in the GEN partition. But you 
*do* need an MMU for that. Without an MMU, you have to tell, at task 
build time, what absolute addresses your task is going to be linked to.
If you have a mapped system, you just task built all tasks against 
address 0, and let the hardware sort it out, and at that point, you can 
also have as many tasks in partitions as you care about, without 
worrying about address clashes as well.

Or rather, you could have had several tasks in the GEN partition of 
unmapped systems as well, but you would have to task build them to 
different addresses in order for them to be able to set in GEN at the 
same time.

> -20F was not a general purpose OS.  It reused code from various sources,
> but ended up being its own hybrid thing.
>
> Mapping your own experience with those sources onto the -20F doc will
> lead you astray.  It took enough from the other code to make you feel
> comfortable -- then turned around and did something different without
> telling you.
>
> Truth is in the bits, not your expectations.

That is always true.
And yes, -20F looks truly like a weird hybrid, with even the 
documentation not correct.

>> So some things is not pure -11M.
>>
> Isn't that what I said?  And the doc said?

The documentation seems to be rather inaccurate, though.

>> But looking at a few bits and pieces I manage to find list files for,
>> BOOT.MAC is definitely from RSX-11M. I can even see some of that code
>> still in the latest version of -11M+.
>>
> Probably.  But unless you also have 11D code, don't be too sure.  11M
> practiced code reuse before it was popular.  M may have started with D's
> BOOT.

Nope. The comments in the BOOT sources even says it is 11M.

>> I also found the device driver list files, and you are absolutely
>> right that those do not work like -11M device drivers do. They seem to
>> actually be tasks in some magic way. Very interesting. There are more
>> details I'd like to know, but I don't have the time to dig further
>> into that right now...
>>
> I dealt with 11D in the mid-70s.  Had the joy of benchmarking some telco
> OEM applications - including COBOL.  Yes, COBOL on 11D with
> unaccelerated packed decimal.
>
> I seem to recall that 11D had loadable device drivers that ran as tasks
> (before 11M added loadable driver support.)  But those I loaded; I
> didn't write any.  I rather suspect this was the basis of the 20F drivers.

Loadable device drivers have been around for a long, long time in 11M. 
But, unlike 11D, device drivers in 11M were never tasks.
And the drivers in -20F do appear to be like tasks, and they even define 
the RSX11D symbol, so they definitely are in the 11D vein.

	Johnny