Happy Birthday VAX 11/780 (influence of)
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 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