Re: [hatari-devel] MEMWATCH freezes Hatari

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

Yes, I absolutely agree. Even with a decent documentation this PMMU stuff
is quite special. Using it in practice (with real hardware) helps a lot
to understand how these things work. What's amazing is that with just a few
lines of code one can do a lot of useful (and also crazy) things.
I would have liked to have something like Hatari (especially the trace
capabilities) 30 years ago. This would have saved me a lot of crashes and
reboots :-).

Best regards

Uwe

>    Hello,
>     
>    I'm rather sure already that your interpretation is right -- given that
>    MEMWATCH would not work otherwise on a real TT/Falcon.
>     
>    I was simply making the point that -- from the perspective of someone who
>    has to implement this in an emulator, i.e. Toni -- the documentation is
>    not clear or even incorrect. As soon as one has to actively interpret
>    documentation ("when they say ... they can only mean ...") it's nearly
>    impossible to implement correctly.
>     
>    Regards
>    Christian
>     
>    Gesendet: Freitag, 12. Oktober 2018 um 12:56 Uhr
>    Von: "Uwe Seimet" <Uwe.Seimet@xxxxxxxxx>
>    An: hatari-devel@xxxxxxxxxxxxxxxxxxx
>    Betreff: Re: [hatari-devel] MEMWATCH freezes Hatari
>    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?
>    > > >
>    > > >
>    > >
>    > >
>    >
>    >
> 
>