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

[Rob Landley]

On 09/06/2016 02:26 AM, BGB wrote:
> 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?...

Use the target remote pipe syntax:

  target remote | program-to-run

In which case gdb reads the stdin/stdout of the child process. If the
emulator is connecting the serial port to stdin/stdout, they should talk
to each other naturally.

(If the first argument to "target remote" on the gdb command line is "|"
it takes the rest of line as a command to run. Search for the word
"pipe" in https://sourceware.org/gdb/onlinedocs/gdb/Connecting.html)

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

Yeah, that's pretty much what gdb expects. I implemented netcat -f in
busybox (and toybox) years ago so I could have a program do that to a
serial console. (cat isn't bidirectional. Also, themachine it was hooked
up to was a DIFFERENT machine we had to ssh to, so it called ssh and
then called netcat -f on the remote machine.)

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

The leftmost column of http://www.shared-ptr.com/sh_insns.html is "which
processors implement this instruction". :)

The tl;dr is "sh2 was nommu, sh3 had an mmu, sh4 was multi-issue (could
execute two instructions per clock cycle)". I _think_ sh3 introduced 32
bit floats, and then sh4 introduced 64 bit floats, and I don't have the
instruction set in front of me.

Note that sh3 was only out for a year before sh4 supplanted it. Hitachi
had a plan to introduce a new processor iteration each year, but that
only lasted long enough to sideline sh3. The sh2 chip was used in the
Sega Saturn game console (and _widely_ used in Japan's automotive
industry), the sh4 was used in the Sega Dreamcast (and also in Japanese
industry).

For context, Asia's economy imploded in 1997:

  https://en.wikipedia.org/wiki/1997_Asian_financial_crisis

So after doing SH4 (which was ready around 2000) Hitachi partnered with
NEC in an attempt to save money, and the result got spun off as
"Renesas". As time went on, Renesas developed a MASSIVE "not invented
here" syndrome, created its own chip lines, tried to migrate all its
customers to them, and became deeply embarassed by every technology it
had inherited from Hitachi. (To the point of trying to pretend that its
historical Hitachi connection didn't exist.)

The _problem_ is the asian economic crisis didn't go away, they hit the
zero lower bound and got caught in the liquidity trap Paul Krugman wrote
a paper about: http://web.mit.edu/krugman/www/japtrap.html

It turned into secular stagnation and persisted for a full decade before
the US economy followed suit in 2008. (And only THEN did anybody else
start going "huh, supply and demand are different things, it's possible
to have a demand shortfall you can't fix on the supply side, who'd have
thunk? The Great Depression after the 1929 stock market collapse dried
up demand and the stagflation after the 1970's OPEC oil embargo gave us
a big suppy shock had different causes. Maybe they need different
responses?" Well, they said that for about 6 months and then went back
to pushing on a rope trying to fix demand shortfall with supply-side
changes...)

Anyway, superh got essentially orphaned by the combintation of Japan's
economic woes and Renesas' not-invented-here hitachi tech purge, and
when the last patents expired we scooped up this excellent overlooked
technology and gave it a whirl.

> 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 note that sh2 was developed by a different team (within hitachi) that
did sh3 and sh4. (The sh3/4 guys were the "let's put out a processor a
year, for 2 years!" team. The sh2 guys did their stuff several years
earlier.)

But both were Hitachi, back in the 90's. sh2a was renesas going back
years later and going "sh2 is still selling, we're not sure why, let's
try to glue bits onto that to juice sales". Those patents don't expire
for another decade, but they also didn't do anything particularly
interesting.

Rob