virtual memory

I want to clear my virtual memory concept. Is virtual memory, a part of hard disk or NAND Flash (some indirect addressable memory).

Reply to
khan
Loading thread data ...

formatting link
are you comfusing memory swap with VM?

Reply to
Hlrsr

Virtual memory is frequently on a hard disc but is probably not in NAND flash. Virtual memory is memory that isn't really there. Say you have 16MB of RAM, 100MB of Hard disc and a 32MB of data you want in memory. The first

16MB would go into RAM and then a virtual memory controller would store the remaining 16MB on the hard disc in an file reserved as "Virtual Memory". The program accessing the data will not know or care whether the memory it is accessing is in RAM or on the disc - it all looks the same from outside.

It is not impossible for the virtual memory area to be in a NAND flash but if I would tend to use something that doesn't wear out as it is written to.

Reply to
Tom Lucas

Virtual memory could be both but it is always a bad idea to use flash memory. You'll wear it out very fast.

formatting link

Peter

Reply to
Peter

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.

The terms "physical memory" and "physical addresses" refer to actual memory connected to the processor and directly accessible by it. This is what is meant when you say a system has, say, 256 MB ram. The physical address range is limited by the number of address pins (or chip selects, or sdram address range, or whatever). The physical address is therefore the address seen by the memory hardware.

The "virtual address", on the other hand, is the address seen by software, which can be quite different. There are three possible reasons for making it different - one is to give the software the illusion that it has access to more memory than the system has physically, another is to give the software the illusion of a single contiguous memory block even if the physical memory mapped to the virtual memory is piecewise, and the final reason is to ensure that separate applications have separate memory spaces. A virtual memory system can implement any or all of these systems, with only the first requiring swap space.

Reply to
David Brown

NAND flash could be used to load read-only pages (such as code) directly into physical RAM in demand paging. If the physical RAM becomes full and some pages must be discarded, read-only pages can be discarded and loaded again from the original store (e.g. executable file).

However, modified "dirty" pages needs to be saved into a secondary store (page file) if these pages must be removed from physical RAM to make room for other pages. The page file should not be on the Flash, since the frequent writes to the page file would destroy it quickly.

Unfortunately some operating systems have a tendency to try to purge pages from physical RAM just as a precaution even if the physical memory would be much larger than the sum of all programs ever executed in the system. Thus desktop operating systems should not moved to a Flash only system without doing something to the page file mechanism.

Paul

Reply to
Paul Keinanen

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

Reply to
Roberto Waltman

I'll add my own experience with HP 201x processors and their timesharing system. It also did swapping without any virtual address system involved. A portion of the main CPU memory (there was an IO processor with half the memory, as well), was reserved for the program space and the rest for the timesharing system. In addition, various 'commands' were also loaded into the swap space for their execution, allowing for extending the operating system features.

Not only was their no virtual memory, there was no hardware support for a stack.

I suspect similar things were done on PDP-8s and other computers of that day and earlier, such as the IBM 360.

Jon

Reply to
Jonathan Kirwan

I have done similar - to an extent - things later (mid 90-s) on a 68340 CPU. It had no MMU, but the OS - DPS, which now happily runs on a PPC with an MMU and normal VM - did have dynamic memory cluster allocation from day one. What I did was provide a call (actually a set of calls) for the applications which would allow them to knowingly release (typically large) regions of memory when they did not need them for some time so this memory could be allocated to other tasks (being written to the swap file before that). The application which had released a memory region could claim it back using a call and would get it again contiguosly allocated although perhaps placed at some other address (obviously the code had to be written to take that into account, not a big issue since the actual address was returned by the call). The PPC version actually still supports all that - same old sources - but only old applications use it, I have not (yet?) written new ones to use this mechanism.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

J> >

Reply to
Didi

When did memory management become synonymous with VM? There were memory management units in computers since the early 1960s and except for systems which implemented VM (eg. S/360) they did not use the terminology "virtual address".

BTW, a well-known example of swapping without VM was implemented on the CDC 6000 series running SCOPE or derivatives; tasks or jobs were rolled in or out from a control point by the operator or automatically by job control (under supervision by a PPU program).

Michael Grigoni Cybertheque Museum

Reply to
msg

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.

Reply to
David Brown

The virtual address is the address seen by the software, and the physical address is the address seen by the hardware. They might be the same, and they might be different (in which case, you have a "virtual memory system"), and there may be an MMU or some simpler (or more complex) hardware translating between them. You can also use an MMU or other hardware for other purposes (such as memory protection) without having virtual memory. So although most large modern processors use an MMU to implement virtual memory, the terms are not synonymous (and certainly not synonymous with "memory management", which is a much more general concept).

Such swapping *is* a virtual memory system. If you have two programs on the system at the same time, which each have a different view of memory (for example, each might start at the virtual address 0x1000, but this refers to different code depending on which program is running), then you have a virtual memory system.

Reply to
David Brown

--snip--

It is a matter of nomenclature; the CDC 3300 for example implemented a paged memory management unit but did not have VM; translated addresses were never referred to as 'virtual'

The 6600 did not have VM hardware; the O/S handled relocation and memory management. Programs were not coded to virtual addresses nor did they have different views of memory. Many systems of the era handled swapping of jobs and/or job segments (tasks) without using VM hardware. The benefit of ECS (extended core storage) on the upper 6000s was mainly to speed swapping (avoiding the drums or large disk files -- eg. 807,

808, 824, etc.)

Michael Grigoni Cybertheque Museum

Reply to
msg

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

Reply to
Jonathan Kirwan

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.

Clear as mud, as my gran would say :-)

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).
Reply to
David Brown

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:

Which makes no sense to me. It's circular. It's just defining things in terms of the same things.

Yup.

Elsewhere you had also written:

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:

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

Reply to
Jonathan Kirwan

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.

Reply to
David Brown

If in doubt, ask Da Wiki:

formatting link

Not sure that helps, though ;).

My take: virtual memory == ( physical memory != addressable memory). Not to be confused with pipelining/cacheing.

Steve

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.