[J-core] qemu updates / roadmap

[Rich Felker]

On Mon, May 16, 2016 at 12:11:48AM -0400, Christopher Friedt wrote:
> >> 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).

r2 should contain the same value as r0 at the time of the and
operation; the mov.l in the delay slot loads the value that was
previously stored from r0 to @r1, from @r1 into r2.

One possible thing that might go wrong (in emulation or cpu
implementation) might be the mov #-4,r1 clobbering r1 before @r1 is
loaded into r2.

> 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.

I don't see anything that looks odd/incorrect, but understanding what
part of it you think is odd/incorrect might help me identify what
you're confused about.

> 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?

There's jtag code in the source, but I don't think it's fully working
and I don't know if it's hooked up for the Numato board anyway. It
might be more productive to build a simulation target instead and use
that for low-level debugging.

Rich