Re: [hatari-devel] question about natfeats' code

[ Thread Index | Date Index | More Archives ]

Le 23/10/2014 00:17, Eero Tamminen a écrit :

On keskiviikko 22 lokakuu 2014, Nicolas Pomarède wrote:
in hatari-glue.c, I see that in OpCode_NatFeat_ID() and
OpCode_NatFeat_Call() we have :

          Uint16 SR = M68000_GetSR();

I see that we need to read SR to check for supervisor bit, but why is
there a call to SetSR after with the saved value "SR" ? As far as I can
see, natfeats.c doesn't alter SR in any way, so this SetSR seems
unnecessary to me.

Likewise, but does Exception() & M68000_BusError() called on errors
do something that might require reseting SR back to original value
on return?

M68000_BusError() will call Exception(), and this will change SR, because the exception set the S bit and will call the corresponding vector handler.

But in that case, if natfeats require to call Exception() because some parameters are wrong or not recognized, then the 68000 code should be in supervisor mode, as if it made an error itself.

If you restore SR before going back to the 68000 program, then you will be in the exception handler, but without the correct SR bit ; this might not necessarily cause a problem if the handler doesn't do any supervisor-only operations, but this is wrong.

I don't use natfeats myself a lot, could you try to remove the M68000_SetSR(SR) and see if it still behaves as expected when natfeats is called with an unknown command ?

For the cases where the natfeats command is OK, then M68000_SetSR will just set te same value as what is was before, so it's redundant.

(main reason for this change is that I want to update hatari-glue.c in a way where the code is not dependant of the cpu core and/or compatibility level, we should avoid as much as possible to have reference to the cpu core's inner variable (suc as ir or irc) outside of uae-cpu/ or cpu/ directory)


Mail converted by MHonArc 2.6.19+