Jonathan Kirwan wrote:
> On 10 May 2006 09:26:41 +0200, David Brown
> <david@westcontrol.removethisbit.com> wrote:
>
>> Jonathan Kirwan wrote:
>>> On 9 May 2006 20:23:39 +0200, David Brown
>>> <david@westcontrol.removethisbit.com> wrote:
>>>
>>>> Roberto Waltman wrote:
>>>>> David Brown wrote:
>>>>>> No, you are confusing virtual memory with swap space. The concepts are
>>>>>> related, but not identical. In particular, you can have virtual memory
>>>>>> without swap space, but not vice versa.
>>>>> This is not correct. I have worked with a RTOS on Hewlett-Packard
>>>>> minicomputers that did not have any support for virtual memory, (no
>>>>> MMU, no traps on accessing invalid addresses, no restartable
>>>>> instructions, etc.) but did support swapping.
>>>>> At "sysgen" (system configuration) time you could partition the memory
>>>>> not used by the OS itself into non-overlapping regions. When linking a
>>>>> program, you had to tell what region it should use. More than one
>>>>> active program could use the same region, (i.e. they were linked to
>>>>> use the same physical memory,) and the OS would swap them in and out
>>>>> (to disk) as needed.
>>>>> This was a standard technique before MMUs became common place, as well
>>>>> as support for "Program Overlays", which we could call a poor man's
>>>>> swapping mechanism. (Anybody still using overlays?)
>>>>>
>>>>> Roberto Waltman
>>>> Ok, fair enough - overlays (of various sorts) are a form of swapping
>>>> without requiring virtual memory. Perhaps it would be better to say
>>>> that software transparent swapping requires virtual memory. It is also
>>>> worth noting that virtual memory support does not necessarily require an
>>>> MMU - a simple system could use trapping on invalid accesses (as you
>>>> mentioned above), either supported by the processor / microcontroller,
>>>> or by external hardware.
>>> Just to keep splitting hairs a bit, the swapping that took place on
>>> the HP O/S I was working on in the early part of the 1970's was
>>> transparent to the programmers working at their terminals. The
>>> swapping took place quickly enough that they rarely even saw a delay.
>>> And from their programming point of view, they had a well-defined and
>>> unchanging view of the system. No matter which one of the 32
>>> timeshared users you were, it all looked exactly the same to you.
>>>
>>> So, I suppose it would be interesting to me if you would more
>>> carefully define what you mean by "software transparent swapping" that
>>> "requires virtual memory." I extended a simple, standard programming
>>> model to all timeshared users. They were swapped. There was no
>>> virtual memory system. It was all transparent to the programmers.
>>>
>>> At least, I think so until I hear back from you about what exactly you
>>> meant.
>>>
>>> Jon
>> I think we have strayed so far into the twilight zone that I can't tell
>> what's black and white any more. This system gives software transparent
>> swapping to each application, but only for a limited range of memory
>> (since swapping it into physical memory is all or nothing). Since the
>> application cannot transparently and directly access any part of the
>> "memory" (even if it has permission), it is not a complete software
>> transparent virtual memory system. But you still have a mapping between
>> the physical memory (i.e., ram), and the logical memory image (some of
>> which is on disk at any given time). The logical memory image is the
>> virtual memory.
>
> I'm not sure how to take all that. The terms seem mighty vague.
>
> Let me put it this way: "Suppose your system has only 10k word to it.
> Suppose the addresses start at 0 and proceed consecutively up to the
> limit. Suppose your program runs in that physical memory space."
>
> Now, tell me. What's not complete about this? Yes, the memory range
> is limited. But that's not uncommon for any system. (We can suppose
> that there is an O/S sitting in, say, the upper 6k work of a 16k word
> machine -- for purposes of talking about this.) It might very well be
> that the system _actually is_ a 10k word system, after all. The fact
> that there is an O/S hypothetically sitting somewhere a little higher
> up really is a rather unimportant detail from the perspective of the
> program. And this isn't that much different that systems which use
> hardware to map in the O/S into each process's address space, is it?
>
> Then you go on with this kind of vague terminology saying that "it is
> not a complete software transparent virtual memory system" as though
> that helps anything. You are just stringing words together here and
> defining things circularly, I imagine.
>
> I can tell you firmly that as far as software development went, each
> programmer on the system operated as though they were the only user on
> it.
>
> So I guess from what you write that you are left saying is the
> following:
>
>> --> software transparent swapping requires virtual memory, because
>> --> it is a complete software transparent virtual memory system
>
> Which makes no sense to me. It's circular. It's just defining things
> in terms of the same things.
>
>> Clear as mud, as my gran would say :-)
>
> Yup.
>
>> If something is "virtual", it means it is not really the way you see it,
>> but you can pretend that it is. A "virtual terminal" does not require
>> its own monitor and keyboard, but the software can pretend that it
>> *does* have a monitor and keyboard. "Virtual memory" does not require a
>> direct one-to-one linear physical memory, but the software can pretend
>> that it does. Your system provides some of that but not all. If asked
>> to give a yes/no answer, I'd have to say it does have a virtual memory
>> system, since it is certainly not directly mapped. However, all this is
>> sufficiently in the grey area that it is purely my own opinions as to
>> what counts as "virtual memory", which are no more valid than anyone
>> else's (and less valid than those of someone who has actually used the
>> machine).
>
> Elsewhere you had also written:
>
>> --> The virtual address is the address seen by the software,
>
> Let me take this last one to task for a moment and then return to the
> adjective 'virtual.'
>
> For a widely known example, you need only look at the modern x86
> processor. It includes a segmented address layered upon a linear
> address layered upon a physical address. It is the segmented address
> that is seen by the software, which does _not_ see the linear address
> and definitely does not see the physical address. The segmented
> addresses are translated via the GDT and LDT into linear addresses,
> which are then translated via the paging system into physical
> addresses. Upon all of this, one may (but doesn't have to) add such
> things as allocating physical memory to pages and/or rolling them in
> and out of physical memory (and perhaps, but again not necessarily)
> linking that physical memory into the page mapping of some process.
>
> But the gist here is that even in the x86 and even when the operating
> system goes to lengths to set up the descriptors so that things all
> appear to a program to operate like a single memory system all to
> itself, it is still most fundamentally a segmented system. You cannot
> execute code via the selector used for data, for example. And the
> programmer _must_ be aware of this fact. The programmer is exposed to
> the segmented system.
>
> In other words, I don't think just calling the "address seen by the
> software", by definitional fiat, virtual. Is a segmented architecture
> virtual? If so, is then the linear address that isn't strictly seen
> by the software, but instead seen by the paging hardware, also
> virtual? And if not, it really is the paging hardware that has the
> appearances of providing virtual memory, does it not? And if so and
> if you also consider the segmented addresses also to be virtual,
> aren't you conflating ideas?
>
> I think it would be helpful to think a little more closely about how
> you use terms to describe things and to increase your precision. Let
> me toss out another use of virtual which I suspect you've also heard;
> "Virtual printer support." What is that? How might that concept
> apply elsewhere? How is that related to memory systems? Can it be
> applied to processing, itself? What about other resources?
>
> I have a very difficult time really understanding this, though:
>
>> --> software transparent swapping requires virtual memory, because
>> --> it is a complete software transparent virtual memory system
>
> Circular meanings like this are not very useful. And I took the first
> phrase from an earlier post of yours I took issue with and the second
> one from the post I'm responding to when you tried to explain what you
> meant. So I think this is a fair juxtaposition to pose to you.
>
> Jon
I'm obviously expressing myself rather badly here. I agree that what is
needed is a precise definition of the terms involved - not just
"virtual", but probably "memory" as well. I think, however, that we'd
go through more vague explanations trying to get there, and still not
agree on the details, and I'm not sure that will help the original
poster or those who followed up who were confusing swap disk space with
virtual memory, but I'll give it a brief try. Does the following make
sense?
If the software can directly access memory at addresses that do not have
a direct correspondence with physical addresses in the system, then it
has a virtual memory system.
In a system using swapping, if the swapping happens transparently to the
software while it is running, then it is a virtual memory system. If
the software has to actively swap in the memory (by operating system
call, or setting an extra address latch, or whatever), then it is not a
virtual memory system.
In the case of your HP OS, I suppose by those definitions the system is
a swapping system from the OS's viewpoint, and neither virtual nor
swapping from the user applications' viewpoint.