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

[BGB]

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 
handled.

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 
an ISR.

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.