[J-core] working on SH-2 emulator.
cr88192 at gmail.com
Mon Sep 5 00:19:05 EDT 2016
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.
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
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
> 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.
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
... 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
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 )
More information about the J-core