If you trace it, DmWriteCheck is a bit more code than you might expect.
DmWrite always calls DmWriteCheck before proceeding.  It then makes a
system call to lock a resource semaphore and reprogram the memory
management hardware in the dragonball.  After the actual Memory Copy,
the hardware is programmed again and the semaphore released.

This is essential, since we don't want buggy programs trashing the
user's data.  But, if records were protected by hardware, then in place
editing would be safer for applications.  This eliminates the software
bounds checking and the memory copy.  Writing is faster and less dynamic
heap is used.

-jjf

-----Original Message-----
From: Oliver King-Smith [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 25, 2000 9:53 PM
To: Palm Developer Forum
Subject: RE: End Of Dragonball? Palm Shakeup?


Actually to get back to my original point.

I like DmWriteCheck.  It really prevents problems.  It can be a pain to
use
it, but the time it saves and the stability it ads is really worthwhile.
Is this the slow function or is DmWrite slow?  DmWriteCheck is
presumably
all done in software, and I would guess is not that substantial.

At 04:28 PM 4/25/00 -0700, you wrote:
>
>
>> 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?

I agree this sounds like Windows NT.  I don't want that - I want the
current system.

>
>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?

A larger heap would be nice too, but DmWrite is so slow that I am
nervous
about storing stuff in multiple records, even it makes smaller more
robust
code.  If I need to write back to 20 or 30 records, things slow up from
the
user perspective.

>
>-- 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

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palm.com/devzone/mailinglists.html

Reply via email to