Re: [hatari-devel] Natfeats doc?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 8.9.2021 18.59, Thorsten Otto wrote:
> On Mittwoch, 8. September 2021 17:39:00 CEST Eero Tamminen wrote:
> > Or you inline the opcode.
>
> That won't work (at least not by just specifying the opcode). The interface is
> designed to expect a normal function call, including the return address, and
> parameters starting at stack offset 4.
>
> What you could do is something like:
>
>    move.l nf_debugger_id,-(a7)
>    clr.l -(a7)
>    dc.w 0x7301
>    addq.w #8,a7
>
> But even then you would still have to step over the addq when returning.
>
> Changed registers should normally not be a problem; the only register that is
> modified by the call is D0.
>
> Another possibility would be to specify a new opcode for just this purpose,
> eg. 0x7302.

Where args are expected directly in stack without offset, and D0 is not 
modified regardless of
whether the call has an error or not?


Should it also clear out the parsed parameters
from stack (i.e. in NF_DEBUGGER case increase
A7 by 4)?

Not giving correct number or correctly sized
parameters in stack, or NatFeats not being enabled
could then lead to really hard to debug problems
though...


Or did you mean that it would be used just for
invoking debugger, like user-space breakpoint?

In that case, I think it would be better to use
already existing instruction / opcode for that,
either:
- "illegal" ($4afc), or
- "bkpt" ($4848 + vector)


> Would be also another method of invoking the debugger, but tightly
> related to natfeats, and i think better than some XBIOS call, or catching
> access to some I/O address that should normally trigger a bus-error.

Thomas, Nicolas, what do you think,
could consuming 3rd opcode for NatFeats
be a problem for it?


	- Eero