#Virtual Memory Wishlist
20 messages in this thread
Virtual memory would be a god-send, IMHO. For the techies: is there ANY
way that VM could be made into chip mem? It would seem impossible, but then
there's Dave Haynie…
— Ethan
Ethan,
Virtual memory doesn't require any hardware except an MMU…so you
can leave Hazy out of it. As to virtual CHIP memory…I doubt that's
practical at this point in time. Imagine the problems that'd be caused by
a page fault in video memory. CHIP RAM used for video memory is
essentially "real time" RAM and it has to be there exactly when needed. It
can't wait for a swap in from disk. Figure the same for RAM used for
audio.
Another use for CHIP is disk buffers….again, not real smart to
page fault a disk buffer, and then have to read it in from disk just to see
if it holds the data you need.
While some of that can certainly be gotten around by locking
certain pages in real memory…by doing that, you've lost the ability to
use VM in the first place…so why build it if you can't use it (for CHIP
RAM that is).
Don
I don't think virtual memory would be that much of a godsend to the Amiga.
Using virtual memory would be nice for doing "ordinary" applications,
however, it would wreck the ability of the Amiga to do
real-time multitasking(the one thing that makes it the best multimedia
box). It would still multitask, but not in real-time.
John
John, as long as you didn't go beyond your maximum amount of memory you
will still get real-time multitasking. That would seem logical, although I
haven't taken O/S yet in college and hardly claim to be able to program an
MMU.
— Ethan
Ethan,
If you don't go beyond your real memory…then there's no need for
virtual memory.
That is, unless you want absolute load programs. Then, even though
all programs could fit in physical memory…you'd need an MMU to translate
address references from the absolute address to the real address.
Don
Then there is no need for VM. Since you already have all the memory you
need, you don't need to add any more by using VM. And once you start
creating page faults due to the need for VM, performance drops off rapidly,
depending on the number of page faults.
John p.s. However, VM would be worthwhile if they make a
multiuser/network server version of Amiga DOS.
John, I don't think you understood me. You had said that a negative
against VM is that you lose real-time multitasking. My point is you get
your choice, you can get real-time multitasking OR VM. I think people
should have that choice.
— Ethan
Not true. There is nothing that is inherently incompatible between virtual
memory and multimedia. A full-blown VM system should let you specify what
pages are not eligible for swapping. This can be used to keep realtime
performance realtime.
When you anayze realtime programs, most of the code (and, usually, most of
the data) does not need to be realtime. There are usually only a few parts
that absolutely need to be kept in memory at all times. The other parts
can be brought in as needed.
I write realtime software for VAXen running VMS (an extremely virtual
memory oriented OS). Doing an analysis on a VAX 11/750 (a machine that is
slower than a 68020), we found that a page fault from disk took 50-70
milliseconds. This is fast enough for most human oriented interaction.
Things that needed faster response time are locked into memory.
BTW – As far as multitasking is concerned, this system was also running
things like networking software, FORTRAN compiles, editing files, etc.,
while running the realtime code.
Chris
Kinda what I figured. No hard-drive could keep up with the demand, and
the blitter isn't accustomed to waiting.
— Ethan
"Virtual memory would be a god-send"
And then you curse it when you actually have to use it..
Roger, that depends how it is implemented, and whether or not it can be
shut off!
— Ethan
To implement VM, you need an MMU. Normally, the MMU goes between the CPU
and physical memory. Chip memory is characterized by being the memory that
the custom chips access. Since the custom chips do not go through the CPU,
they would not go through the MMU either. Consequently, the custom chips'
usage of chip memory would not be virtual (although the CPU's usage of chip
memory could be).
In any case, timing constraints would make normal virtual access of chip
memory, i.e., swap to disk, unpractical. But, as long as we are blue
skying, it might be practical to have chip memory "swap" or remap to fast
memory. You still could not have more memory usable by the custom chips at
any given time than they can address, but you could have a large
"extended-chip" space that could bring in the memory when needed, possibly
even remapping at 60Hz. With the current AmigaDOS, however, this would be
a software nightmare.
Chris
You don't need an MMU for virtual memory, all you need is indirected
memory, which can be done quite well without hardware support. That's what
the Mac and Microsoft Windows do. Instead of getting a pointer to memory
when you AllocMem(), you get a ptr to a handle, and there are other
functions that turn a memory handle into a valid memory pointer. The
system is free to swap out the memory that belongs to handles that aren't
tied down.
Of course, an MMU buys you hardware memory protection, keeping tasks from
trashing each other when they go wrong. It doesn't buy you everything,
though, because few operating systems do any bounds checking on the
arguments you pass to system functions, meaning a bad program can still
bring down the system.
Well, I had always been taught that what the Mac and Windows do is object
management, a form of overlaying. Normally, virtual memory is considered
to be something that happens without the direct involvement of the program
that is executing.
As far as bounds checking, it may not be common on micros, but any mini or
mainframe that wants to be regarded as a "real" multiuser platform has to
do it. Quite often there is a way of asking the MMU whether or not the
user is really allowed to change memory that the OS has been asked to
modify.
Chris
After seeing how it works on the Mac and Windows, I'm sad that we didn't
have handle-based memory management on the Amiga. Without an MMU, you get
(effectively) virtual memory. With an MMU, the handles make it much easier
to swap out pieces of memory. With them, the OS knows when an application
is using a given piece of memory. send
I agree, that works, but: 1) It puts extra work on the programmer AND
it's extra overhead. 2) The chunks would be of varying size, which makes
the memory management a lot harder. 3) It'll only work well with data; code
would have to remain resident. What are you going to do? Have "function
handles" that you convert into "function pointers"? The OS would bind the
code every time is gets swapped.
— John
Windows 3: Aunque la mona se vista de seda, mona se queda.
Extra work? I *like* the extra safety that better memory management gives.
'malloc' and 'free' are *NOT* serious memory management for microcomputers,
until Unix-like virtual memory is the norm. Good micro programs need to
clean up after themselves and manage memory to a greater degree than
'malloc' already. For serious applications, handle-based memory is a
blessing, not a hassle.
Didn't understand your Windows quote, but Windows does have code swapping,
too, and it's rather transparent. In essence, it does have "function
handles", in that any function pointer is actually a pointer to a code stub
that checks if the code is swapped in or out, and if it's out, it gets
swapped back in before you jump to it. The table of stubs is always in
memory, but it's probably small, if you're correctly labelling things as
'static' functions, or not. Swapping is done on a module-by-module basis.
This scheme also allows code to be shared. It's not different than
swapping schemes implemented by overlays in conventional Amiga compilers,
except it's done naturally at an OS level. There's lots of things to learn
from other operating systems!
There is another thing to consider. Virtual memory requires an MMU. An
MMU will also give you memory protection. If the memory map is kept on a
task by task basis, as opposed to a system wide basis, tasks can be
protected frwould greatly reduce the number of GURUs seen. However, this
change would require extensive ADOS mods.
Chris