#WB 1.4 News
11 messages in this thread
The problem comes if memory which has been swapped out is accessed during
interrupt processing, and some other trap/supervisor functions. In these
states, you could not access the disk driver. Thus there would need to be
some memory blocks which are never swapped out, which could be flagged with
the "MEMF_VIRTUAL" bit (or lack thereof). …cheath
What if all interupt service routines were forced into CHIP RAM? I
would presume that CHIP RAM would be "unswappable" by it's very nature?
That'd be fine if you could force everything that is and is accessed by
interrupt code … forcing it anywhere. Problem is there is no way to do
that, without building something into the memory allocator, as best as I
can see. There's no way to force existing code to put memory which could
not be accessed as virtual memory into a particular type of memory; thus
the only thing I can see to do is to add a VMEM bit for memory
allocations.
Charlie, there already IS a bit to deal with this: MEMF_PUBLIC. I quote from
the early ROM Kernal Manual Vol 1 page 1-62.
MEMF_PUBLIC
Indicates that the memory requested is to be used for different tasks or
interrupt code. This would be for task control blocks, messages, ports and
so on. the designation MEMF_PUBLIC should be used to assure compatibility
with future versions of the system.
I interpret that paragraph to mean that MEMF_PUBLIC memory will NOT be
swapped out in a virtual memory system. No need to invent any new flags,
just use the ones we already have.
But practically all software uses MEMF_PUBLIC already, which means the
virtual memory mapper would not be winning much. Also I imagine there are
a sufficient number of interrupt things which do not use MEMF_PUBLIC as to
make it practially unimplementable, without throwing out a lot of code,
which won't be obvious until until somebody actually tries to implement
virtual memory. Simple enough to say "but those programs are breaking the
rules!!!", but that won't get you very far when you try to boot your system
and it hangs.
As a simple example, what should LoadSeg do with memory allocations? There
are hunk-definitions for memory type, but it has never mattered if
something threw in the "public" bit or not.
Charlie, I'm gonna disagree again on this one. If programs are already
using MEMF_PUBLIC for everything, then they didn't read the manual, and the
programs are BROKEN. Also, I cannot help it if peple do NOT read the
manuals before they write code (interrupt code not using MEMF_PUBLIC). I
find the idea of adding a bit because many earlier programmers were to lazy
to do it right to be abhorrent. You, of course, realize that if you add a
NEW bit, no program will run.
OK, you are right – the MEMF_PUBLIC bit is the one which could be used for
VMEM support. This is something near and dear, since I've considered
offering a virtual memory manager as a product until Commodore gets it
built into the system. My analysis was that it is something which will
break many things, some of them at the OS level … and thus it wasn't
something I'd be able to sell because I couldn't fix everything else which
breaks, and thus it would be useless even though "correct".
Adding a new bit would allow everything to run, but nothing would take
advantage of the virtual memory unless it uses the new bit. But that,
also, rules out a 3'rd party addition. So it'll probably have to wait for
Commodore, in V1.5, and will probably break a significant number of things
(even though the things that break will be "at fault").
My interpretation of MEMF_PUBLIC is that it allocates memory that will not
be mapped to a particular task, i.e. "public" memory would be available to
all tasks, "private" memory (~MEMF_PUBLIC) could be protected from other
tasks – depending on presence of an MMU. This, of course, has nothing to
do with virtual memory since public or private memory could be swapped in
and out as needed.
Don, except, the docs explicitly state that interrupt code can reference
public memory, it _better not_ get swapped out.
Or we could use the bit which is _already_ defined MEMF_PUBLIC
I don't think MEMF_PUBLIC fits the bill; interrupts don't have any
restriction on accessing memory which is MEMF_PUBLIC. It could be declared
that anything which is not MEMF_PUBLIC could be made virtual … but that
would rule out most memory allocations, since most applications use
"MEMF_PUBLIC" by default; and it would still break many things, since they
weren't designed with this in mind (IE, there's no particular reason why an
interrupt routine would not access both public and non-public memory at
this point)