bqt at softjar.se
Sun Oct 31 05:37:47 CDT 2010
On 2010-10-30 23:18, "Chuck Guzis"<cclist at sydex.com> wrote:
> On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
>> > If your program vrites data to address 0, and reads it back, and get
>> > the same data back, and another program on the same machine, at
>> > roughly the same time, write to address 0, and reads the same data
>> > back, and that data is different than the first programs data, then
>> > I'd say you have virtual memory.
> So, your definition ties virtual memory into multi-user access?
> That's not the way I learned it.
No no no. You miss my point. It don't directory tie in to multiuser
access. It's about presenting to you a memory which in reality does not
exist as you perceive it. As a follow on benefit of this is the fact
that you can have multiple instances at the same time. But that is not
The definition is that you appear to have a linear space of memory that
maps the whole virtual address range, and that this memory is yours
alone. It is your own private memory. Just as a virtual machine is your
own private machine. No matter the fact that in reality, this is not the
case, and your memory (or machine) is just something running under the
control of an underlying operating system, which gives you this service.
> Consider (again folks, I'm sorry for the reference) the CDC 6600
> (circa 1964). Every user is given a relocation address (called RA)
> and field length (FL) as a way of partitioning main memory. Each
> user's memory addressing space is kept isolated from every other's
> and this fits your definiton because one user's location X was
> different from every other user's location X and there was no way for
> a user to tell what his RA was; i.e. each user was safely "boxed in".
The important question here - are the programs aware of the RA register,
and can they change it? And can they address the full range of memory
addresses as perceived by the program.
> That's not virtual memory by any stretch of the definition. Over-
> committing memory meant writing/reading the entire FL of a user to
> disk ("rollout" and "rollin").
Another word for swapping in and out?
Anyway, I'm not sure if this would qualify as virtual memory or not
without knowing a few more details. But it might very well be virtual
memory, as far as I can tell.
> Now consider the STAR-100 (I think it would qualify as the first
> virtual memory machine of CDC), circa 1969.
Defined by whom? CDC? Or you guys? ;-)
> Every user got an
> addressing space of 48 bits, but the machine itself had only
> 512Kwords (64 bit) of physical storage. For production use, most of
> the time the system was run in single-user mode (kept thrashing down
> with large data sets). That fits my definition of VM because the
> user was fooled into thinking that there was more physical memory
> than there really was.
You know, my definition and yours don't necessarily disagree on all
points. Both would define the VAX as having virtual memory (well, except
for the fact that yours might not, if you have a VAX with enough
physical memory). We just disagree about what when there is more
physical memory than you have virtual memory space. For you, that means
it can't be virtual memory. but for me it can.
For me, what is relevant is whether the program is presented with his
own private memory space, which contains all addresses he can address,
and where all those addresses are valid and working. A memory space
which he don't have to share with anyone else. That's what virtual
memory is, as opposed to physical memory, which you can point at, and
which all running code on a computer needs to live on. And that means
that the OS is always there. And possibly other processes as well. Using
the same addresses you are. If that means that you cannot have your own
memory for a specific address, then it's not virtual memory. But then
you probably aren't talking about virtual memory either, but physical
> Aside from expanding program storage, the large addressing space was
> used to map file space (another type of "memory-mapped I/O"), so file
> access was actually performed through the paging hardware/software.
> That was kind of cool, as the STAR was a memory-to-memory vector
> machine, so you could use vector instructions on entire files, rather
> than have to issue reads and writes for pieces of a file.
> So I think we differ considerably in our definitions.
On some parts, yes. So, do the VAX not have virtual memory? After all, I
can fill a VAX with more physical memory than you can address virtually.
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