Re: OS calls.

[hyc@locus.com (Howard Chu)]

  > Line F is used on 030 machines for floating point, I think; and it's used
  > by early TOS versions (the ones that don't run on 030's :-)) internally
  > by the AES to call the VDI.
  > 
  > I would be quite surprised if the actual calling mechanism (trap vs.
  > line A or line F) turned out to be a significant factor in system call
  > timings. I would think that the context save/restore code would be the
  > most significant part (at least for MiNT). Anything that we could do
  > to speed those up, and/or to generally speed up the kernel's handling
  > of system calls once control reaches the kernel, would be a big win.

  Well, yes. We jammed the context save/restore code on the RTU down into
  about 20 opcodes. If we generated hardware specific kernels (68000 only,
  68030 only, with fpu, without fpu), we could save ourselves a chunk of
  code, and save a LOT of cycles on the Context-Switcher From Hell.

  But, yes. The use of the Line-A trap _does_ make a significant difference.
  That's why it _is_ used for the low-level graphics primitives, rather than
  using a spare trap.

OK. As for hardware-specific kernels - how about just jumping through a
function pointer? Initialize the table when mint.prg starts up.