On Date: Tue, 25 Apr 2000 16:39:20, krollin writes: >> 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? I don't have my history books in front of me, but MMU's have over 4 decades of development behind them. Page based MMU's are only one type among many. There are paging non-translating MMU's, non-paging translating MMU's, base-and-bounds based MMU's, segment descriptor based MMU's, memory bank based MMU's (that one should be familiar here!), and many other hybrids. There are MMU's that have hardware translation, software translation, and/or combined schemes. There are MMU/cache combinations of several different kinds. Etc., etc. An MMU which could limit access of an application to its stack, the application heap, and only requested memory mapped records could go a long way to make the PalmOS more crash proof (and thus more user friendly to those who like to try new applications). Setup for MMU protected (and/or translated) memory mapped database records could be done at record request and release; thus allowing multiple intervening r/w accesses with zero overhead. Palm Inc. is probably a large enough volume consumer of chips that they should be able to specify a custom CPU/MMU/cache/DSP combination to provides some optimized combination of features targeted for the cost, low power usage and fast UI response required for their target applications. IMHO. YMMV. Ron Nicholson HotPaw http://www.hotpaw.com/rhn/hotpaw/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palm.com/devzone/mailinglists.html
