30 Oct
2010
30 Oct
'10
2:55 a.m.
On 2010-10-30 01:12, Ethan Dicks<ethan.dicks at gmail.com> wrote:
Well. A PDP-11 can restart an instruction if needed, and you get a trap
when trying to reference virtual memory that isn't enabled in the MMU.
SO all the components for demand paging is there in the hardware.
Overlays solve a different problem, so it's not really meaningful to
compare them to demand paging. Even if an OS on the PDP-11 had demand
paging, you would still need to use overlays exactly the same way as
now. Overlays solves the problem that the virtual address space is only
64K. Demand paging does not solve that. Demand paging solves the problem
of not needing to have all virtual address space mapped to physical
address space at the same time, thus saving on physical address space.
You could say that demand paging makes more efficient use of physical
memory. And it is also required if you want to map more virtual memory
than you have physical memory. (But we already hashed through that :-). )
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
On Fri, Oct 29, 2010 at 12:31 PM, Chuck
Guzis<cclist at sydex.com> wrote:
Indeed. Finally someone with the correct definition of virtual memory.
You could also draw the parallel to a virtual machine. It fakes a real
machine, making you think that you have your own. Virtual memory fakes
real memory, making you think you have your own.
Exactly how this is done is not a part of the definition. Nor is the
relation between the sizes of virtual and physical memory relevant.
If you get the impression that you have the full address range available
to do with as you please, even though you are not alone on a machine,
then you are presented with virtual memory.
> On 29 Oct 2010 at 0:11, Johnny Billquist
wrote:
>
> >> Next question: Does the VAX not have virtual memory any more now that
> >> I've pointed this out? Or do you need to redefine virtual memory in
> >> yet a new and strange way to exclude the PDP-11...:-D
>
> I think that using memory address spaces to qualify the "virtualness"
> of memory is following the wrong animal.
>
> I would define "virtual memory" as the ability to fool a program into
> thinking that it has more physical memory than is actually present.
I
don't think that's an essential component of the term as I learned
it 20+ years ago.
My understanding is that in a machine that supports virtual memory,
you have virtual address space(s) and physical address space.
Physical addresses are something you can see with a logic analyzer and
point to a physical chip and say "my data is right*there*". If you
have two processes running on the same CPU, they both agree where
0x0000 (or 0x00000000) is and it's the same place. If one process
writes a value there, both processes would read that value back. In
virtual space, each process*thinks* they are writing to 0x0000, and
they can read back the value they wrote, but not each other's values.
In fact, unless they peek under the covers, they have no idea where in
physical memory their own virtual 0x0000 is. In practice, quite often virtual memory_is_ used to
fool programs
about how much physical memory there is, but the PDP-11 is a specific
counter-example to "more than is actually present". Taking the VAX
first (since we all know "all the world's a VAX";-), you might have
8MB of physical memory installed in an 11/750 in a physical memory map
of 16MB (24 address bits). So in this model, your virtual space is 32
bits (the size of your address registers), while your physical space
is 24 bits. From the process side, every process "sees" 4GB (32
bits) of space with lots of holes in it (mostly holes). If your
program keeps requesting more and more memory from the OS, at first,
you may be given chunks of real memory mapped into your virtual space;
eventually that will be exhausted and your OS will most likely start
paging and reserve storage for you until that runs out (so always
check the return of malloc() even if you think you can't possibly run
out of virtual memory).
Yes. You could also say that demand paging is *required* in order to
fool a program that it has more memory than what is physically
available. And virtual memory is also required to make this work, but
they are two different things. You can have virtual memory without
having demand paging.
On the PDP-11, your process's_virtual_ space is
64KB - 16 bits, the
size of your registers, while some PDP-11s can have up to 256KB of
physical memory (18 bits), and many can have up to 4MB (22 bits) of
physical memory. In this case, you still have virtual space different
from physical space (and the same scenario where two different
processes agree on where 0x0000 is in physical space but maintain
their own 0x0000 in their respective virtual spaces).
Exactly!
> So, can
a PDP-11 with 16K of memory appear to a program as if there
> were 32K present?
That all depends. Back in the day, what we did was not
demand-paged
virtual memory (something supported natively on the VAX and the 68010
(but not effectively on the 68000) - some architectures have memory
management hardware that can "tell" if a reference is about to hit a
patch of virtual addresses that don't have physical memory mapped to
them and invoke some OS-specific routine to either allocate or pull
from storage what needs to be there and resume the instigating
instruction as if nothing happened (which is part of what
distinguishes the 68010 from the 68000 - instruction restart).
On the PDP-11, we used overlays to load, say, 32K of code into 16K of
physical memory, pulling in routines when they were needed, but it was
done at the application level, not the instruction level. It is not
the same thing as demand-paged virtual memory (which_is_ used to make
it seem that there is more memory than physically installed).
5167
days inactive
5167
days old
0 comments
1 participants
participants (1)
-
bqt＠softjar.se