[J-core] working on SH-2 emulator.
cr88192 at gmail.com
Tue Sep 6 03:26:54 EDT 2016
On 9/6/2016 12:53 AM, D. Jeff Dionne wrote:
> On Sep 6, 2016, at 2:46 PM, BGB <cr88192 at gmail.com> wrote:
> Oh, excellent. This means you have passed all the CPU tests, and dropped into a GDB stub. Did you implement and test the J2 CAS instruction, or patch it out?
I implemented all the instructions which were tested for, including CAS.
had to do a bit of looking to figure out how CAS was supposed to behave.
the main instructions which gave me trouble here were MAC.W and MAC.L
(mostly in the saturate modes), and the DIV instructions, as these were
harder to get the logic right.
there were a lot of misc things which were broke and needed to be fixed
(the tests turned up a lot of random things which didn't work right).
> If you connect this to GDB as a 'remote', you can load code using gdb, run and (mostly) debug.
I am guessing this would imply using a TCP socket or something?...
currently the program is a console program which uses stdin/stdout for
input/output (but is OS specific in terms of needing to implement
non-blocking console IO).
I am also a little confused as the code looks like it should go into
"main_sh()", but I am not seeing much evidence of this happening (it
seems to go straight to the debugger blob), but it seems this could be
possibly due to with issues of how GCC was built.
I am mildly uncertain about the relation between SH2 and SH4, as looking
at the SH4 spec there seem to be a lot of things which are different
from how they seem to be done in SH2.
for example, SH4 seems to have a different memory map, differences in
the initial processor state, and differences for how CPU exceptions are
I could almost add an FPU and MMU, though there are some details of the
SH4 MMU which give me some hesitation (particularly WRT the use of
raw/exposed TLBs and cache state, which IMHO shouldn't really be exposed
architectural features). would otherwise assume the use of page-tables
(and a page-table focused interface to the MMU), but then I guess maybe
one can argue that a bit of complexity would be needed in hardware to
deal with HW page-table to TLB mapping and similar vs offloading it to
I guess a compromise could be leaving it up to processor-specific
firmware, where a normal OS gives the CPU some page-tables, and more
CPU-specific firmware implements the ISR which does the TLB management.
though this strategy leaves open the question of where the CPU keeps
this ISR (given VBR is provided by the OS). the simplest, but most
tacky, option would be to expect the OS to copy these table entries from
the firmware (1).
FWIW (1): actually, in a few places the MSP430 basically did this, where
some particularly core-specific functionality was provided by a separate
(smaller) ROM space, and code would copy values from this space (at
predefined addresses) into the respective processor registers.
More information about the J-core