CompuServe Messages

The 68040 MMU (Memory Management Unit) is radically different to the degree that I will be supprised if there ever is an enforcer program for it. Enforcer requires a MMU. You need to protect and detect accesses to certain memory areas and only a MMU makes that possible. To sum up the problems with the 040 MMU (there are at least four): The first is MMU page size. The 030 can protect an area as small as 256 bytes. The 040 is limited to an area of either 4K or 8K. A 1K area is needed for enforcer to protect the exception vector table. If I create a 4K entry, you need to trap the access, determine if the write is to the exception table or to the legimate portion of chip ram, rewrite the MMU tables, execute the write while in Supervisor mode, rewrite the MMU tables, all while disabling interrupts. Fun. Number two is that enforcer/mungwall keeps track of memory you've allocated and print out anytime you are accessing an area you aren't supposed to. The 4K granularity of the MMU means that 4K areas of RAM will be allocated (to prevent another task from allocating that same space) for as little as an 8 byte allocation by your program. Number three is that caching can't be controlled separately from the MMU address translation tables (ATCs). There is a cache on/off bit which affects both caches in the ATC tables for each page entry. The 030 MMU could create a separate set of tables which could control the data cache separately from the instruction cache on a page by page boundary. Number four is the ATC table search tree is fixed at three levels. This means a miss in the ATC requires three memory accesses to find the proper translation for an individual 4K or 8K page. There are 128 table entries in the internal MMU cache, (64 for instruction accesses, 64 for data) which helps a lot. The 030 only had 22. The 030 had the ability to create a tree with one to five levels. A branch could be effectively pruned to one level for a table search, covering a much larger area and is much faster. The 040 can only prune the tree for invalid pages, which generate an illegal address exception (crash). The missing feature is called early page termination. The lack of early page termination really hurts the overall performance capability of the MMU. The dual 4K caches (instruction & data) are the only saving grace here. Number five (see, I knew I could come up with more than four!) is when the MMU is disabled, all memory is set cache enabled in writethru (nonserialized) mode. This is somewhat safe as the caches are turned off at reset/power-up, but in another OS which might turn on the cache too early, boom! Motorola should have been a little conservative and set the default mode to non-cachable, serialized access mode. Because the MMU is so different, the encoding of the opcodes were all changed to force an exception. This is good as it will do less damage for a system to go dead when 030 MMU instructions are encountered than to go on half working, perhaps doing real damage to hard drives, etc. The saving grace is that the 040 has four special MMU bypass registers called Transparent Translation registers, two for each cache. When these are enabled, a memory area is not translated and the logical address passes through to physical addresses within a clock cycle. Careful programming of these registers gives some rudimentary control of independantly turning the caches on or off relative to some memory address ranges. You need at least four of each to properly map the A3000 memory map, including the ZorroIII space (but there are only two). The PP&S CPU040 program just sets/resets the cache enable bits of these registers. A potential problem is that for A3000 users, the PP&S default MMU setup may not work with non-RAM (i.e. I/O) ZorroIII cards since they turn on caching in the ZorroIII area. Of course ZorroIII I/O cards are real popular and plentiful right now! -Greg – via Whap!