[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.
> Right. Line-F is part of the coprocessor calling interface, it's used on
> 68020 and up for any coprocessor - I suppose math and MMU are the only
> ones that ever existed in widespread use.
> 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.
> According to my 68020 user's manual, the Trap #x, Line A, and Line F
> instructions all have identical timing characteristics. I don't think this
> line of investigation is going to go anywhere.
The timing characteristics are the same, but the operational function of
them is not. With a lineA/F you peek at the instrtuction that sent you
hence, and that's your opcode. You can suffix that with data, rather than
stack-pushing, or you can set up an A5 call-stack, so that data is always
in a known location. This saves the classic motorola 'which stack is the
damn address/function code/argument on' dilemma, and saves you a heap of
code. Certainly a call-stack would save a fair bit of time in itself. AES
VDI and lineA all use variations of this technique.