[J-core] working on SH-2 emulator.

[BGB]

On 9/4/2016 11:55 PM, D. Jeff Dionne wrote:
> On Sep 5, 2016, at 1:49 PM, BGB <cr88192 at gmail.com> wrote:
>> On 9/4/2016 11:14 PM, D. Jeff Dionne wrote:
>>> I second all of that, but with one caveat: qemu doesn't try to be pipeline accurate, and I'm not even sure I know what that means as soon as you are multi issue.  What I think you really mean is ISA internal state consistent, which (unfortunately)  does expose a bit of pipeline state the way the ISA was originally designed.
>>>
>>> What I personally would like to see is if someone could take ownership of the test rom, which was originally done by someone who had an itch to scratch ;) and extend it with corner cases...
>>>
>> for some of this funkiness, in my case I ended up reordering the instructions in the decoder (so, after decoding, the operation in the delay slot appears before its associated branch instruction).
>>
>> I don't know if this is sufficient.
> Immediate reaction is this likely doesn't do it, because...
>
> ...
>> though, there could be other issues, like funky register-dependency semantics or effects on the calculation of PC-relative addresses or similar that I am not presently aware of (I have had a bit of an issue making sense of the exact behavior of PC-relative addressing in this ISA).
> This.  There is a long thread on the list here that talks about these issues.  There are instructions that are illegal in the delay slot, and while for the most part, pipeline hazards are taken care of (look at the bypass logic in the register file RTL for instance) at least the PC relative calculations do expose some implementation details, resulting in counter intuitive behaviour.

yeah. I did the PC relative calculations as a fixed offset relative to 
where the instruction originally appeared, so will probably need to look 
more into this. thus far this strategy appears to work, but as-noted it 
may not be foolproof.

guess is, if it is not at the usual space ("PC+i*N+4"), could either be 
at offset "PC+i*N+2", or alternatively be relative to the PC at the 
target location (which would be non-trivial to support with the current 
implementation).

may need to go try to find the thread.


otherwise, I thought the "illegal in delay slot" thing was more a thing 
telling people not to do stuff (as opposed to something for the emulator 
to necessarily need to deal with). but, may go address this (probably 
with instruction flags in the decoder, if decoder sees a delay-slot 
instruction with this flag set, will replace it with an "illegal in 
delay slot" trap or similar).


testing the boot code, I noticed that all it seemed to do was set the 
GPIO outputs a few times and then go into an infinite loop.

didn't figure it out until looking more at the source, realizing this 
means it failed a test.
guess this means probably beating on stuff and making it work.

fixed issue, now it updates GPIO outputs some more, and tries to access 
a bad address, hmm...
(ok, it seems it goes into the infinite loop in "testmov", and then 
faults out of the VM when a timer interrupt hits it and there is a 
garbage value in VBR).

luckily, my emulator helpfully also has a disassembler which shows the 
execution path and dumps registers and similar (but, I still need to 
match up the disassembly with the ASM code).


but, seems to pass the "testbra" test at least.
appears to currently be dying in "testmov".

so, will probably go beat on it some more...