[J-core] qemu updates / roadmap
Rich Felker
dalias at libc.org
Sun May 15 23:01:10 EDT 2016
On Sun, May 15, 2016 at 10:43:47PM -0400, Christopher Friedt wrote:
> On Sun, May 15, 2016 at 11:53 AM, Christopher Friedt
> <chrisfriedt at gmail.com> wrote:
> > On Sun, May 15, 2016 at 11:00 AM, Christopher Friedt
> > <chrisfriedt at gmail.com> wrote:
> >> 0x3290 <_pfail> .word 0x0000
> >> 0x3292 <_pfail+2> sub r2,r6
> >> 0x3294 <_testgo> mov #-117,r0
> >> 0x3296 <_testgo+2> mov.l 0x3610 <_pram0>,r1 ! 0x6594 <_ram0+128>
> >> 0x3298 <_testgo+4> mov.l r0, at r1
> >> 0x329a <_testgo+6> nop
> >> 0x329c <_testgo+8> bra 0x32a0 <_bracont>
> >> 0x329e <_testgo+10> mov.l @r1,r2
> >> 0x32a0 <_bracont> mov #-4,r1
> >> 0x32a2 <_bracont+2> and r1,r2
> >> 0x32a4 <_bracont+4> mov r2,r0
> >> 0x32a6 <_bracont+6> cmp/eq #-120,r0
> >> 0x32a8 <_bracont+8> bt 0x32ae <_bracont+14>
> >> 0x32aa <_bracont+10> jmp @r13
> >> 0x32ac <_bracont+12> nop
>
> I think this makes a bit more sense now - _bracont is a corner case.
> Normally, bra should be followed by a nop. If it isn't then "strange
> and wonderful" things happen. Presumably, all of the contention
> behaviour documented (and undocumented) have been built into the jcore
> design.
>
> I think what I've observed here in Qemu, are some of those contentious
> behaviours not being correctly addressed!
Could you elaborate on what you mean by "contentious behaviors"? This
is just a standard branch delay slot as far as I can tell; there's
nothing unusual or unexpected about having non-nop instructions there,
and although there are a few instructions you can't use in delay
slots, mov.l is not one of them.
Perhaps qemu has a bug in the case where the branch destination is
exactly the instruction after the delay slot, which is somewhat
special in the sense that the branch just behaves like a nop.
Rich
More information about the J-core
mailing list