[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OS calls.
> 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.