Re: [hatari-devel] MEMWATCH freezes Hatari

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Christian,

I failed to dig out the copy of the 68030 book I used when implementing
MEMWATCH. I must have hidden it well. Would have like to see what this
book actually said.

I guess I will verify our different interpretations of the Motorola spec
in practice. Not with Hatari, of course, but on a real Atari ;-).

Please correct me if I am wrong: You suggest to set the S bit of the
copy of the SR that has been placed on the stack instead of modifying
the copy of the SSW?

I'd expect that after RTE the processor is *and will stay* in supervisor mode,
because my undestanding is that the processor will restore its internal
state based on the stackframe data.
Additionally, it you are right, how and when would the processor switch
back from supervisor to user mode after the RTE? It was in user mode
before the exception, so it must return to user mode. Or RTE handles the
SR copy differently depending on what caused the exception, which I'd
find inconsistent.

Best regards

Uwe

> Hi,
> 
> Well, this chapter is dealing with the SSW, not the SR. When they say
> Status Register they can only mean the SSW. Everything else does not make
> sense in the context of the whole chapter. But if they mean the SSW everything
> makes perfect sense and reflects how it's actually working.
> 
> Best regards
> 
> Uwe
> 
> >    Hello,
> >     
> >    the wording in the 68030 User's Manual is at least misleading then. I know
> >    of course that MEMWATCH works on a real 68030, but this is imho not fully
> >    documented.
> >     
> >    Have a look into section 8.4 of the User Manual for the Bus Cycle Fault
> >    Stack Frames ($A and $B). You can see that (as for every exception) the
> >    Status Register is at the top (=lowest address) of the stack frame, while
> >    what you modify is the Special Status Word. The sentence you quote below,
> >    however, explicitly makes explicit reference to the Status Register (not
> >    the SSW): "the privilege level indicated in the copy of the status
> >    register on the stack".
> >     
> >    I still don't see the bit of documentation where it says it will use the
> >    modified SSW.
> >     
> >    Regards
> >    Christian
> >    Gesendet: Freitag, 12. Oktober 2018 um 10:55 Uhr
> >    Von: "Uwe Seimet" <Uwe.Seimet@xxxxxxxxx>
> >    An: hatari-devel@xxxxxxxxxxxxxxxxxxx
> >    Betreff: Re: [hatari-devel] MEMWATCH freezes Hatari
> >    Hi,
> > 
> >    Please see section 8.2.1 in the MC68030 user's manual. I used a
> >    different book:
> > 
> >    https://www.abebooks.com/9780201088762/68030-Assembly-Language-Reference-Includes-0201088762/plp
> > 
> >    when writing my PMMU-related tools. The faulted instruction in this case
> >    may be anything that tried to write to a write-protected page, i.e. a
> >    page write-protected for user mode writes based on its page descriptor.
> > 
> >    The user's manual says:
> > 
> >    If a rerun
> >    bit is set when the processor executes an RTE instruction, the processor
> >    may
> >    execute a bus cycle to prefetch the instruction word for the corresponding
> >    stage of the pipe (if it is required). If the rerun and fault bits are set
> >    for a
> >    stage of the pipe, the RTE instruction automatically reruns the prefetch
> >    cycle
> >    for that stage. *The address space for the bus cycle is the program space
> >    for
> >    the privilege level indicated in the copy of the status register on the
> >    stack.*
> > 
> >    Best regards
> > 
> >    Uwe
> > 
> >    > > ---> It asks the CPU to retry the instruction that caused the bus
> >    error
> >    > > in the first place in supervisor mode.
> >    > > 0001ED10 BSET.B #$0002,(A7, $000b) == $00005707 [11]
> >    > Ok, so this code sets SSW FC2 bit and then reruns faulted data access
> >    > and CPU uses SSW FC mode to access the faulted data? Is this documented
> >    > somewhere? I didn't find anything about CPU supporting modification of
> >    > SSW FC bits.
> >    >
> >    > Current data fault restart part of emulation does not use modified SSW
> >    > FC which probably explains the problem. Hopefully emulating this
> >    > properly does not get too nasty... Other bits should be already
> >    emulated.
> >    >
> >    > btw, what is the actual faulted instruction?
> >    >
> >    >
> > 
> >     
> 
>