Re: [hatari-devel] extra bits in PC register (was: "profile stack" command added)

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On lauantai 01 kesäkuu 2013, Nicolas Pomarède wrote:
> On 01/06/2013 17:56, Eero Tamminen wrote:
> > Unrelated question.  Why in cart_asm.s:
> > -------------------
> > 
> > ; This is the cartridge header:
> >          dc.l    $ABCDEF42           ; C-FLAG (magic value)
> >          dc.l    $00000000           ; C-NEXT
> >          dc.l    sys_init+$08000000  ; C-INIT - flag has bit 3 set =
> >          before
> > 
> > disk boot, but after GEMDOS init
> > 
> > $08000000 is added to sys_init address?  What's the flag bit 3?
> > 
> > 
> > When TOS goes through cartridge code and jumps to that address
> > (which does linea_init variable setup for Hatari), PC gets an "illegal"
> > address value.  Emulation itself masks the extra bits off from the
> > address, but profiling code throws a fit about it when I profile
> > TOS startup...

I commited a workaround that masks the extra bits away when profiler
reads the PC value.


> I don't know why it does that in this precise case, but as pc is 32 bits
> and 68000 addresses 24 bits only in st, you can indeed "store" data in
> the upper 8 bits.
>
> If you look at the exception vectors in lower ram set by TOS, you will
> see that exception 2 has "02" in upper byte, exception 3 has "03", ..
> 
> So if your program crashes, as pc will be pushed in the stack at one
> point, it can help to debug to see what caused the jump to the current
> state of the 68000  (for example, after a bus error, pc will be 02xxxxxx
> ; so you know you're in the context of a bus error (this is valid only
> when the tos set such handlers))

What happens on 030 and machines which have fast RAM i.e. more than
16MB of RAM?


	- Eero