[J-core] qemu updates / roadmap

[Christopher Friedt]

On Sat, May 14, 2016 at 10:50 PM, D. Jeff Dionne
<Jeff at se-instruments.com> wrote:
> On May 15, 2016, at 9:10, Christopher Friedt <chrisfriedt at gmail.com> wrote:
>>
>> I actually had to disable CONFIG_CPU_TESTS because otherwise I was getting stuck in _fail.
>
> That is not necessarily ok to do.  While there are a few instructions that will not be available unless you've coded support for them, tests for those (and maybe it's only CAS.L actually) should be #ifdef out and the rest shown to pass.  The easiest way to do that is to bring the LED port out to a console print (in qemu) and see where it stops.  The tests count in BCD, the top 4 bits are the instruction 'group' and the lower 4 the test number in the group.  I would want to know at least which instruction is failing, (other than CAS.L).

True.

It looks like the error is actually arithmetic in nature, because the
branch to _fail happens (below) at 0x32aa. I've verified that's the
case by using a source-unmodified version of boot.bin / boot.elf
compiled with the suggested bare-metal toolchain, as well as using my
previously supplied patches (that allow me to compile / test on Mac).

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

What it boils down to, is
-117 (r0) & -4 (r2) != -120 (r2)

This op actually results in r2 containing a value of 0, which would
imply that the ALU ops for SH in Qemu need a bit of love.

> During the debug of the CPU, this is/was fundamental to being able to tell exactly -what- wasn't/isn't working quite right.  It tries to check for corner cases, etc.  There is a pretty good chance if you can get to 0110 0010 test passing, you can call the CPU emulation 'good' and assume any problems are likely elsewhere.

Indeed..