On Fri, Oct 29, 2010 at 12:31 PM, Chuck Guzis <cclist at sydex.com> wrote: 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). 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 processes agree on where 0x0000 is in physical space but maintain their own 0x0000 in their respective virtual spaces). 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 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). -ethan

On Fri, Oct 29, 2010 at 2:26 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote: I know it works well enough in early Sun workstations and the AT&T Unix PC (3B1/7300), but I have no knowledge of any required workarounds due to possible bugs. I have no memory of issues with instruction restart on the '10, but I didn't use that feature of the chip when I was doing embedded product development 20+ years ago (we only used it for the "loop mode" 1-instruction cache feature that allowed so-called "DBcc loops" to run ~50% faster due to not needing fetch cycles while in the loop). Could what you remember be something to do with "instruction restart" vs "instruction continuation"? (a distinction I was not making, but now that I've read this - http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm - perhaps that's a better way to describe it). -ethan

On 29 Oct 2010 at 13:39, Ethan Dicks wrote: I suppose that it's a matter of who you're asking. There were a number of interpretive compilers (e.g. JRT Pascal) on the x80 that claimed to implement virtual memory. And COBOL had, starting very early, to segment code by grouping paragraphs into sections that could be read in as needed. Not data, however. On the 8-bit x80 systems, there were a couple of multi-user implemenatons that provided for a page-mapping RAM with the ability to interrupt on "page not present", in effect, giving each user his own address space and the ability to page to disk. I don't know if that counts or not--one could also view it as glorified bankswitching. --Chuck