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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 23/10/2014 00:17, Eero Tamminen a écrit :
> Hi,
>
> 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();
> > then
> >                   M68000_SetSR(SR);
> >
> > 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)

Nicolas