[J-core] Fwd: ISA manual for SH-2
cr88192 at gmail.com
Fri May 26 00:11:57 EDT 2017
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
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
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
there would be different schemes for NoMMU with PIC and
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
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
More information about the J-core