schoet@UCBVAX.BERKELEY.EDU (Steve Schoettler) (03/10/87)
Paraphrasing Perry Kivolowit:
> What if third party vendors were to put am MMU on a CPU board?
This raises a few concerns for me:
1.We need to have a standard way to use it: Exec library routines
(or maybe even a seperate MMU.library?) to find out if an MMU exists
and to set/read its registers.
You don't want the library routines to be chip specific, so simply
returning a pointer to a memory-mapped chip location is not sufficient,
as register locations would depend on the chip type.
Don't forget the ability to override and restore registers concerning
system memory space. A program that knows what it is doing should be
able to modify Execbase or Library vectors, etc., and then restore
protections. Obviously the machine could die if the program went
haywire here, so a bombproof method wouldn't allow user programs to
modify MMU registers at all. A more correct way to modify system
structures would be to only allow the MMU registers to be modified
when in supervisor state and provide routines to move a byte or block
into system memory. This isn't bombproof, either, as any program has to
have the ability to call the routines, but this method should allow such
programs to be easily debugged. Anybody have a "more" bombproof method?
I feel Commodore should be the one to establish the calling procedure
for these routines. Third party hardware vendors who provide MMU's
in their products can create or replace library vectors with their own
routines during the autoconfigure process.
2.We all should realize that simply adding an MMU would not save the
system completely after the crash of a program that left signal bits
allocated or left a device or library open. A complete rewrite of
Exec would be required, and I doubt that CBM or third parties are
interested in this. We might, however, have a hope of doing it right
with MINIX.
3.How many Kickstart routines need to be modified? When
AddTask() needs memory, for example, does it call AllocMem() through
the library interface or just use a relative or absolute branch?
In other words, would replacing AllocMem and Freemem fix everything,
or are there other ways programs can get memory?
[Actually, AllocMem seems to be in the lower DOS Library memory, in
which case calling the routine is probably done correctly and
consistently from Kickstart.]
In answer to your question, Perry, I think that if the above criteria
are realized or accomplished, you would see interest from many people
(myself included) in rewriting the AllocMem and Free routines.
It's not as simple as it seems, but I say go for it!
Steve Schoettler
ucbvax!schoet
Nobody is responsible for me.dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/10/87)
Unfortunetly, though AllocMem() does have flags for public (MEMF_PUBLIC) and private (0), not many people seem to be abiding by these. In fact, I'm one of them (though not on purpose)... I usually AllocMem(bytes, 0) so I don't have to include exec/memory.h -Matt