Happy Birthday VAX 11/780 (influence of)

Johnny Billquist bqt at softjar.se
Fri Oct 29 14:02:41 CDT 2010


On 2010-10-29 17:34, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2010 Oct 28, at 2:46 PM, Johnny Billquist wrote:
>> >  On 2010-10-28 23:02, Brent Hilpert<hilpert at cs.ubc.ca>  wrote:
>>> >>  How about the notion that the PDP-11 was where several prior but
>>> >>  then-topical innovations coalesced into one machine/architecture?
>> >
>> >  I think that would be a very dubious, and hard to prove claim.:-)
> It may be more work than proving an individual claim of innovation, but
> it is still a plausible notion to research historically.

You're right. And it might be true. Just hard to prove.

>>> >>  ...
>>> >>  On the topic of memory, I would agree with Johnny about "virtual
>>> >>  addresses", but differ on "virtual memory": virtual memory to me has
>>> >>  always meant demand-paging where the RAM address-space seen by the
>>> >>  user
>>> >>  can be larger than the physical RAM, distinct from the simple mapping
>>> >>  of addresses, but the use of the term is a matter of definition.
>> >
>> >  Thank you.
>> >  But what, pray tell, would you say a virtual address pointed to, then?
>> >  Magic smoke?:-)
> Physical memory via the MMU; this is not a contradiction.

You know, a virtual address on a VAX points to physical memory via the 
MMU as well. :-)

The point of virtual memory is that appears as a single, continous 
memory space, even though it might be scattered all around in physical 
memory, and you can have several virtual mappings for the same memory 
space, which do not translate to the same physical memory.
That is what defines virtual memory, I'd say. Not how many bits there 
are, or by how the OS reacts when you address memory for which you not 
currently have a valid mapping.

>> >  Why are people so hung up on physical memory size vs. virtual memory
>> >  size when they need to define what virtual memory is?
>> >  I just don't get it.:-)
> Because there is a fundamental difference between having your valid
> address space limited to available physical RAM, even if you can map a
> "virtual" address to different places in that RAM, and having a
> transparently addressable (large) address space unlimited by a lesser
> quantity of physical RAM. In the latter it*appears*  (hence virtual)
> that you have more RAM than you actually do. This has always (IME) been
> the common meaning of "virtual memory".

I assume you've seen my post by now, where I point out that the physical 
address space of a VAX was/is 34 bits, while the virtual address is 32 
bits. So you can have the exact same scenario on a VAX that you normally 
have on a PDP-11. :-)

I mean, on the PDP-11, let's pretend you had the exact same 
architecture, but you limited the physical address to 12 bits, would 
that then have meant that it had virtual memory? Just because you put an 
arbitrary lower limit on one parameter?

> I'm too many years away from programming a PDP-11, but while it may as
> you suggest have been possible to do demand-paging in principle, how
> complex might it have been in practice? Trapping an address fault might
> be easy enough, but what about instruction restart/re-execution while
> accounting for all possible side effects that may or may not have
> occurred between the start of the instruction and the address fault.

Not complex at all. But the OS would have to keep some more data around 
to be able to figure out where to page in data from when a page fault 
occurred, as well as keeping track of allocated physical memory in a 
different way than any current OS do. RSX (which is the OS I know best) 
can keep physical memory usage tracking simpler since you always 
allocate chunks of physical memory, not pages. And the executable part 
of a program is just one chunk, even though it might be many pages.
And the whole chunk is moved in and out from swap.
A program can, however, have several chunks mapped in. Shared libraries 
are their own chunks, and you have a lot of other kind of chunks as 
well. At most, your program might be referencing around 32 chunks, I 
think. (Don't remember the actual limit, or how it is enforced.)
And a chunk can be more than 64K. It's just that you cannot have more 
than 64K mapped into your virtual address space at one time.

One more potential headache is that the pages on a PDP-11 are variable 
in length. In addition to the page protection bits, you also have a page 
length field in the MMU, so you don't need to allow just nothing, or all 
8K of a page. The granularity of the length is 64 bytes. And you can 
choose whether the top, or bottom part of the page is valid.

As for instruction restartability, it works just fine. DEC did think of 
that. But that is also why I'm saying not all processors could do demand 
paging. You need MMR3 (I think it is), which keeps a scorecard of how 
much registers have been modified by the aborted instruction, so that 
you can back out of it again. Older machines don't have that register, 
and thus cannot undo a partially executed instruction.

> IIRC, the 68000 series ran into this problem when people started trying
> to do (demand paging) VM with it. When an address fault occurred, not
> all of the instruction state was saved and restarting the instruction
> became a problem. It was fixed in the next version but I forget where
> in the series (68010->20, 20->30, etc).

It was a problem in the original 68000. It was fixed in the 68010, 
unless my memory fails me.
One more an example of how much better the PDP-11 was than the 68K. :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol



More information about the cctalk mailing list