On Tue, Apr 25, 2000 at 04:28:22PM -0700, [EMAIL PROTECTED] wrote:
> 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?
If you do few, large, monolithic DmWrites, fine. But if you do a lot
of small DmWrites the overhead is great. If you could simply do a
MemWriteEnable call it would speed things up.
It isn't the speed of one DmWrite, it is the overhead in calling it
dozens of times on the same record, having it perform the same checks,
doing whatever it does to enable writing, actually moving the byte or
two, disabling writing and returning.
You could unprotect the entire record under an MMU, and DmWrite would
still be simpler since it would just have to do the same unlock (and
relock), but the hardware would validate the pointer.
> 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?
Corrupting a heap usually ends with a fatal exception now. Possibly a
clear-reset and a reload. If the app's heap was isolated, and got
corrupted, it could just abort to the launcher.
> 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?
The Dynamic heap is more than adequate under OS 3.5. But the Launcher
is too slow (or whatever it is calling to create the list of DBs) - it
takes several (>10) seconds from when I hit the app button to display
the icons, and a similar time if I want to delete something. I have
500+ databases, mainly midi files and QuoVadis maps, in an 8Mb palm.
It is so slow that it isn't usable! Since OS 3.5 is horrible for my
normal use, I won't go there even for the new features and bigger
heap. I hope it will be fixed soon - maybe it is related to the other
bug.
A larger dynamic heap would speed up the case where you are doing a
lot of byte edits into a buffer (so DmWrite would be too slow, but a
large record woudn't fit into the dynamic heap).
However (and this is why I keep pointing the 68010 core), you then
have to copy the memory between the heaps. Memory moves are over 2x
faster with a loop mode core. Memory fills are 3x. The only thing
faster would be an on-chip DMA channel that could set or move at full
bus bandwidth.
If you are going to do copy-edit-copyback, then you should get a CPU
core that does this fast (and possibly works with misaligned words so
you don't have to special case memcpys since words are 2x faster than
bytes to move).
I'll take either - the next hardware should either speed up DmWrite,
or speed up MemCopy. The latter would help in more places.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
