[J-core] Fwd: ISA manual for SH-2

[BGB]

On 5/25/2017 8:54 PM, D. Jeff Dionne wrote:
> On May 26, 2017, at 10:18, BGB <cr88192 at gmail.com> wrote:
>> I have my own SH variant (currently mostly independent of J-Core;
> To be clear, are you working on a core (RTL) or a simulator?

still mostly ISA-level emulation, a C compiler, and a sort of primitive 
mock-up OS ("testkern").

the ISA extensions exist as optional features for the CPU emulator and C 
compiler.
     the C compiler was mostly because I don't terribly want to muck 
around in GCC.
     sadly, I still haven't matched GCC in terms of performance or 
stability (1).
     currently it is only producing statically-linked ELF output.
         support for dynamic linking is still on the TODO list.

testkern still isn't really a "real OS", as it still lacks proper 
application launching or multiple processes.
     these are on the TODO list, as some other things I want to 
experiment with will require these.
     plan is to support both MMU and NoMMU cases.
         might also want to test relative performance of PIC vs 
base-relocatable binaries.
         there would be different schemes for NoMMU with PIC and 
base-reloc code.
     it is probably rather unlikely that I will do a GUI for this 
(outside of project scope, ...).
         though, I do have relatively a fancy set of extended escape codes.
         (experimentally, can render Quake1 just using escape-codes... 
though at unrealistic bandwidth levels).


1: currently, my compiler output seems to be typically around 1.5x to 2x 
slower than "gcc -O3".
though, this is mostly in wall-clock time; I see a significant drop in 
MIPS relative to GCC's output, rather than a significant increase in the 
total number of instructions executed (may need more investigation).

it does currently seem to be faster than "gcc -O0" at least (which has 
both higher instruction counts and higher wall-clock times). tried "gcc 
-O1", but for some unknown reason I seem to be getting bugs/crashes in 
programs built with this option.

all this has been while producing plain SH4 code.

there is also an SH2 mode, but as-is, this basically just kills FPU 
support and similar (as opposed to supporting a soft-FPU); and is mostly 
untested.

it is still likely to need a fair bit more work/debugging/... before it 
is "ready for general use"; and maybe trying to optimize more for size 
and performance than trying to optimize how readable the disassembly was 
in the process of trying to hunt down codegen bugs.


I hope to be able to do a VHDL / FPGA version of my extended SH ISA at 
some point, but sadly don't have an abundance of time or money at the 
moment (most of my time recently going into classes; and it may take a 
big chunk of time to learn VHDL). so, this is rather unlikely in the 
near future.