usr/src/sys/hp300/DOC/TODO.hp300

1. Create and use an interrupt stack.
   Well actually, use the master SP for kernel stacks instead of
   the interrupt SP.  Right now we use the interrupt stack for
   everything.

2. Copy/clear primitives could be tuned.

3. Sendsig/sigreturn are pretty bogus.
   Currently we can call a signal handler even if an excpetion
   occurs in the middle of an instruction.  This causes the handler
   to return right back to the middle of the offending instruction
   which will most likely lead to another exception/signal.
   Technically, I feel this is the correct behavior but it requires
   saving a lot of state on the user's stack, state that we don't
   really want the user messing with.  Other 68k implementations
   (e.g. Sun) will delay signals or abort execution of the current
   instruction to reduce saved state.  Even if we stick with the
   current philosophy, the code could be cleaned up.

4. Ditto for AST and software interrupt emulation.
   Both are possibly over-elaborate and inefficiently implemented.
   We could possibly handle them by using an appropriately planted
   PS trace bit.

5. Make use of transparent translation registers on 030 MMU.
   With a little rearranging of the KVA space we could use one to
   map the entire external IO space [ 600000 - 20000000 ).  Since
   the translation must be 1-1, this would limit the kernel to 6mb
   (some would say that is hardly a limit) or divide it into two
   pieces.

6. Better time keeping.
   We could use the second timer on the chip to monitor the interval
   timer ("clock") and detect lost "ticks".

7. Conditional MMU code sould be restructured.
   Right now it reflects the evolutionary path of the code: 320/350 MMU
   was supported and PMMU support was glued on.  The latter can be ifdef'ed
   out when not needed, but not all of the former (e.g. ``mmutype'' tests).
   Also, PMMU is made to look like the HP MMU somewhat ham-stringing it.
   Since HP MMU models are dead, the excess baggage should be there (though
   it could be argued that they benefit more from the minor performance
   impact).  MMU code should probably not be ifdef'ed on model type, but
   rather on more relevant tags (e.g. MMU_HP, MMU_MOTO).

8. DELAY() is not even close to right.
   Should use a timer on the clock chip instead of approximating with a
   "while (--count);" loop.  Because of caches, the latter is potentially
   way off.

9. Redo cache handling.
   There are way too many routines which are specific to particular
   cache types.  We should be able to come up with a more coherent
   scheme (though HP 68k boxes have just about every caching scheme
   imaginable: internal/external, physical/virtual, writeback/writethrough)