Re: OS calls.

[root@thelbane.brisnet.org.au (Dancer)]

> 
> 
>   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.

D