[Info-vax] OpenVMS.Org quick pool

[Johnny Billquist]

On 2012-08-24 15:55, Stephen Hoffman wrote:
> On 2012-08-24 13:22:59 +0000, Paul Sture said:
>>
>>
>> This didn't mean that any Dibol program could exceed 32K, just that we
>> could run more of them concurrently and hence support more users.

Right...

>  From ancient and failing memory.... Modula? Modula2? implemented the
> memory management "shenanigans" in the language run-time for RSX-11M?,
> IIRC.

Hmm. I could see other languages do the same trick under the hood, 
especially if you implement a virtual machine. In fact, I've done this 
myself, for the Z-machine on RSX. Programs can be much larger than 64K, 
and the Z-machine does memory remappings as needed, without the program 
ever being aware of it.

Also, overlays in RSX allows you to get the same functionality without 
your program noticing either, by using memory resident overlays. You are 
never able to directly address more than 64K (as always), but overlays 
can be memory resident, and just mean a memory remapping instead of a 
disk read, if you want to. Much faster, but do require that you have 
more physical memory available.

> This same windowing was also trivial to do as far back as on an Apple II
> box, though that required add-on expansion memory hardware designed to
> permit windowing.  Those add-on boards were fairly common back then, too.

It's very trivial, yes. However, it don't really get you around the 64K 
addressing limit. It gives you a way of getting more code/data into the 
existing 64K by changing the contents at times in part of that virtual 
address space.

> With some applications back in that era, folks used multiport memory,
> which required you to deal with windowing, and with another processor
> that could be playing in your memory asynchronously.  The MA780 was the
> VAX multiport part, and the building block of the VAX-11/782.  I don't
> recall the details of the PDP-11 capabilities off-hand (eg: the
> seldom-seen but variously discussed PDP-11/74), but a quick check of
> some /70 does show references to multiport memory.

The only multiport memory I'm aware of was indeed the MKA-11 for the 
11/74. It's pretty much the same memory as the MK-11 for the 11/70, but 
with four ports instead of one.
And you could, in theory, have the same memory box appear in different 
physical addresses on the different CPUs, but RSX didn't use the memory 
in that way. Instead it was all presented in the same way to all CPUs, 
and the 11/74 had a fully shared memory, as seen by the OS.

I'm not entirely sure how you use the word "windowing", or what you mean 
exactly...

The 11/782 is very different from the 11/74, in that the 11/74 was truly 
SMP, while the 11/782 was ASMP, as well as (as far as I understood) had 
both some private memory for each CPU, as well as some shared memory.

> Or - as many PDP-11 users did over the years - replace the PDP-11 box
> with either a VAX, etc., or with a PC running Windows, Linux, etc., or
> (these days) with an Arduino or PLC or similar, and avoid the need for
> windowing.  The particular choices depending on what the PDP-11 was
> doing, of course.

That the PDP-11 many times have been replaced is definitely true. And 
many times it was to get rid of the 16-bit virtual address limitations, 
which forced the use of overlays and many small programs with 
communication between them, and so on...

> These days, dealing with a PDP-11 seems more like somebody involved is
> masochistic (or possibly sadistic), or lost their source code and with
> no budget to replace same, or the wonderfully involved and
> red-tape-entangled mess that is an "approved hardware configuration" or
> whatever the euphemism for "we worked hard so that we can claim we can't
> replace this" is these days.  Well, that or this PDP-11 is embedded in a
> Voyager probe or some such.  The PDP-11 was a nice series of boxes in
> the 1970s and into the 1980s, but that was a few years ago, and better
> and more reliable solutions have become available.

The PDP-11s that I know of still servicing are normally there because 
they work, do the job, and there is no need to replace them. In some 
cases there is also regularly improvements and modifications being done 
to the code for various reasons. Rewriting the whole codebase would far 
outweight any gains you could envision.

So, plenty of them still in steel mills, paper mills, automotive 
industry, and various controller roles. All the ones I know about are 
running RSX, and have track records that survives all the replacemnt 
systems that have been mentioned.

	Johnny