[J-core] qemu updates / roadmap

[Christopher Friedt]

On Sun, May 15, 2016 at 11:01 PM, Rich Felker <dalias at libc.org> wrote:
> 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

Well, it's in testbra.s, for one.

/***********************
 BRA and load contention
 ***********************/
 mov    #0x8b, r0
 mov.l  pram0, r1
 mov.l  r0, @r1
 nop
 bra _bracont
 mov.l  @r1, r2
_bracont:
 mov    #-4, r1
 and    r1, r2
 mov    r2, r0
 cmp/eq #0x88, r0
 bt     .+6
 jmp    @r13
 nop

In any case, I'm no expert in sh assembly, but...

The most obvious thing that caught my attention was that the AND is
performed on r1 and r2, not on r0 and r1. If the and would have been
performed on r0 (#0x8b) and r1 (#-4), then the answer would equal
#0x88 (I believe in the disassembly, it's -120 and -4).

So why would the test have this intentionally odd (seemingly
incorrect) code if it were not testing out some sort of pipeline
optimization (contention is probably the wrong term)? Presumably it
should work correctly on real SH4 (possibly SH2?) hardware.

Pipeline issues are also quite likely, as Jeff mentions in his next post.

Likely Qemu's SH support does not get the pipeline right. For the
tiny-code-generator / translation block aspect of Qemu, it's likely a
bit trickier than doing a pipeline for an interpreting emulator. Maybe
that's what Qemu's 'helper' files are for.

I don't have any actual SH2 or SH4 hardware - is it possible though to
step debug the J2 core running on the Numato remotely? Normally I
would use JTAG for this sort of thing... Alternatively, can anyone
suggest a cheap-ish SH2 or SH4 dev board that can be used with JTAG?