Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory / compatibility
Message-ID: <8905200445.AA20645@postgres.Berkeley.EDU>
Date: 20 May 89 04:45:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 49

: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