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

[BGB]

On 9/4/2016 7:19 PM, Christopher Friedt wrote:
>
> I might suggest you try improving support for SH2 / J2 in Qemu rather 
> than writing your own emulator.
>

I was partly more doing it more for experience, also if I use QEMU would 
be stuck with it being GPL.

the SH-2 ISA is also superficially fairly similar to the MSP430 ISA 
(similar opcode structure, ASM syntax, ...), which I had decent results 
writing an emulator for. from what I can tell, both MSP430 and SH2 took 
some influences from the PDP-11 or VAX-11 or similar (granted, there are 
also plenty of differences between them).

there is also my past x86 emulator, but x86 is a somewhat more complex ISA.

however, for this emulator, did do a few things more like they were done 
with the x86 emulator, namely the use of an explicit "trace cache" (as a 
hash table, where traces may fall out of the cache and be 
discarded/reused), rather than just decoding/translating everything it 
encounters (and keeping it around for an indefinite period of time).


> If you feel up to the task, take a look at my branch.
>
> https://github.com/cfriedt/qemu/branches/all
>

wont rule it out just yet, but feel like trying to see what I can get.

skim: hmm, QEMU does it almost entirely differently, would first have to 
figure out how QEMU approaches doing emulation.


mine uses some nested switches to pick out appropriate function pointers 
and put them into "Opcode" structures, along with setting a few other 
parameters.

after the opcodes are decoded, then the decoder fills in the trace and 
picks out an appropriate "Trace" function pointer, which generally does 
an unrolled loop to call the individual function pointers.

a secondary JIT stage can help with performance, but isn't always done.
generally the reusability of these interpreters (between source ISA's) 
has been fairly low (seems like the cost of generalizing would outweigh 
the potential gains of the implied code-reuse vs doing them one-off).


sort of like with JITs: trying to make a single JIT produce output for 
multiple ISAs tends to have a lot more up-front complexity vs doing 
several smaller JITs specific to each target, well, at least until a 
certain "break even" point is reached where having N simple JITs is more 
of a burden than a more complex JIT that does N targets (by abstracting 
over them).


> Also take a look at some of the previous mailing list history. You 
> *should* run the boot ROM, as it's a very good way to determine 
> whether or not an emulator correctly mimics the internal state of the 
> SH2 pipeline. Unfortunately, Qemu currently does not.
>

ok.


well, tests are nice, since as-is I don't really have a good idea of 
knowing if/how-well anything is working.

if so, will need a binary image of the ROM, as currently the compiler 
binaries I got off the site don't work on my PC (WS4L and Ubuntu 17 
x86-64 seem to just give the message "cannot execute binary file: Exec 
format error"). otherwise would need to fire up my Xeon box and see if 
the compiler works on CentOS.

check: oh, they are i386 binaries... I don't think I can use these...

did some commands online which said they should make i386 stuff work on 
x86-64, but, still no-go (same message).


a more likely option here being to try to get a GCC cross-compiler built 
from source.
... looks like this is gonna be a while ...

getting GCC built is being a lot of hassle, but overall seems to be 
going better than previous times I have tried to build this stuff from 
source. in some ways, GCC is a mountain of random crap held together 
with magic.

and, with any luck, it doesn't all explode into a flurry of error messages.

building stuff for "sh2-none-elf", hopefully this is "good enough".
success, compiler built and didn't explode.

...

ok, got a "boot.elf" built, IIRC this file wasn't here earlier...

testing in my emulator:
     initially didn't fit in the space, tries to load at 0300..6016, 
space was 0000..3FFF
         expanded to 0000..FFFF
     emulator faults, attempt to write to ABCD0000
         ( this part not implemented yet, can do )