scotth@sgi.com (Scott Henry) (05/19/89)
b>Matt Dillon writes:
b>> ... Certainly I would much rather
b>> have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break
b>> too many programs ...
I am wondering, how would it break most application programs? (See my note
below). I can understand problems with handlers (like dmouse/qmouse, etc),
but why would there be a problem with application programs?
b>My two cents:
b>It seems that even those advocating MEMF_VIRTUAL agree that MEMF_PHYSICAL is a
b>better way (exept for maintaining compatability.)
b>
b> [...deleted...]
b>
b>As someone poined out in a previous posting,
b>
b> main(){printf("Hello World!\n");}
b>
b>is a multitasking program on a "proper" multitasking OS.
b>
b>It should also run in virtual memory *by default*
b>
b>
b>OK now everyone tell me why I'm wrong...
b>
I would say that you are not wrong. The intent (as I understand it)
behind virtual memory, is that it looks (to the programmer/user) as a
larger physical address space, and is indistinguishable (except possibly
for performance) to having all physical memory. Locality and frequency of
reference would keep "important" pages in physical memory. Since not all
Amigas will be expected to have VM (similarly that not all Amigas
currently have Fast RAM), somebody would need to write a "fixVMhunk"
program, analogous to the current (and hopefully soon to be deceased, as
all programmers FINALLY know the difference) fixhunk program for fast/chip
RAM. So that if, for example, you have your brand new Amiga 3600 w/VM,
and would rather use dmouse1.10 (which doesn't know about MEMF_PHYSICAL)
instead of the latest dmouse 3.55 :-) which does, why, just fixVMhunk it!
Because VM is *supposed* to be transparent for most (application)
programs, and certainly for most code, I think using MEMF_PHYSICAL, along
with a fixVMhunk-type program to fix-up errant programs would be the
compatible way to go. Note that I don't expect to get VM for CHIP RAM,
only FAST RAM, though this scheme should still work for that, also.
Maybe Commodore should add the MEMF_PHYSICAL flag to 1.4, even though it
wouldn't do anything, just so that it documented well ahead of time...
--
---------------------
Scott Henry <scotth@sgi.com>
#include <std_disclaimer.h>dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/20/89)
:b>Matt Dillon writes:
:b>> ... Certainly I would much rather
:b>> have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break
:b>> too many programs ...
:
:I am wondering, how would it break most application programs? (See my note
:below). I can understand problems with handlers (like dmouse/qmouse, etc),
:but why would there be a problem with application programs?
Now THAT is a good question... ok. what would fail. Hardware
interrupt handlers would obviously fail. Most EXEC-type devices would fail.
But you know, now that I think of it, input-handlers run under a task (the
input.device task), as do file system handlers. Gfx and Intuition? I'm
not sure but those are system libraries and would be appropriately fixed.
Ah... libraries. Libraries would most likely fail since you can't
make many assumptions as to who uses them. But since they are nothing more
than LoadSeg'd executables in LIBS: it would be trivial to 'fix' the hunks.
Anything put on the blitter queue would be in the relm of an interrupt
(??) and that would fail.
Programs which look at system structures via Forbid()/Permit() or
Disable()/Enable() would be in big trouble. Since the page-in would
most likely just send a Seek/Write message to the appropriate file system
handler, this involves going through the system and thus system lists would
change. Even if page-in went directly to a trackdisk.device the
trackdisk.device itself would most likely queue the message to a special task.
(P.S. add a new DOS packet: Seek+Write and Seek+Read to reduce overhead)
What other things wouldn't work? That last one is a biggy.
:currently have Fast RAM), somebody would need to write a "fixVMhunk"
:program, analogous to the current (and hopefully soon to be deceased, as
no need. Amiga's without VM would simply always allocate into non
VM ram no matter what the program requests.
:Because VM is *supposed* to be transparent for most (application)
:programs, and certainly for most code, I think using MEMF_PHYSICAL, along
:with a fixVMhunk-type program to fix-up errant programs would be the
:compatible way to go. Note that I don't expect to get VM for CHIP RAM,
:only FAST RAM, though this scheme should still work for that, also.
The transparency concept really only works when one has firewalls
between application and OS. Otherwise there are usually too many variables
that one would have to consider to 'do it right'.
-Matt