A step at a time - when many people think of MMUs, they think of Intel
'386. The 386 actually has three virtual hardware mechanisms, one for
IO space, Selectors, and Page tables. Selectors actually allow for
fairly small 'virtual' blocks (byte size type chunks), but are limited
in number (8K) and max size (when the smaller size granularity is
selected). Paging is limited to 4K blocks.
Simple MMUs (like the one built into the Dragonball), generally do just
work on large boundaries - but, as the 386 shows, virtualizing heap
allocation size blocks in hardware is certainly possible.
Using the 386 Selector mechanism as an example (I was actually thinking
about an MMU we worked with in a medical instrument recently), when you
get a pointer from a record, you would be getting a selector. Setup
would be basically 3 memory writes. If you try to write outside the
range of the record, you would generate an exception. True, with most
commercial MMUs and high end MMUs build into processors, you would need
to round blocks to 8 or 16 byte size and alignment boundaries - but that
really isn't much different from the current overhead.
You touched on my second point at the end of your post. Currently, the
simple MMU in the Dragonball is used to setup a protected heap and an
unprotected heap. The simple MMU is used to keep errors in apps from
overwriting user data. Access to the protected heap is via OS calls,
which repeatedly check (in software) for over-writes.
Again, using the 386 as an example. You could use 'Selectors' to
protect individual records, speeding up DmWrite (basically eliminating
its need). You could then use a linear address/paging mechanism to divy
memory up between apps and data storage. In other words, memory could
be allocated 4K at a time for either data storage or an app. Even
though the memory is non contiguous in physical memory, it would seem
contiguous to the program accessing it. This would get rid of fixed
heap sizes, and minimize heap compaction - which is pretty time
consuming. I had a Palm Pro which was nearly always full and it would
get incredibly sluggish, spending all its time shuffling memory.
Again, I'm just making the point that you already use an MMU to help
with data integrity and performance. A more sophisticated MMU could
eliminate the overhead and limitations of the software 'MMU' you run on
top.
Best Regards,
-jjf
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 25, 2000 4:28 PM
To: Palm Developer Forum
Subject: RE: End Of Dragonball? Palm Shakeup?
> An MMU could dramatically improve unit performance. Basically,
> DmWriteCheck (which is called a lot) is doing in software what a MMU
> could do more reliably in hardware.
Could it really? How? Let alone that MMUs typically only protect on a
page
sizes, not byte sizes (which you'd want in order to protect individual
chunk).
Let alone trying to keep the protection ranges in sync with the heap
layout
(through memory allocations, compactions, deletions, etc.). But how
would
DmWrite be faster? It would still have to reprogram the MMU to allow
writes to
the specified memory location. Would that reprogramming be any faster
than
what's done now?
Are you thinking of some radically different scheme than what's used
now?
Perhaps one where each application more or less gets its own storage
heap that
it's free to unprotect and (possibly) corrupt?
I think that the real problem is that people feel they are constrained
by the
size of the dynamic heap, and so use DmWrite to get access to more
memory. So
the real solution is not to speed up DmWrite, but to allow larger
dynamic heaps,
and maybe different ones per application. Perhaps that's the problem
that an
MMU could be used to solve. Any ideas here?
-- Keith
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palm.com/devzone/mailinglists.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
