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

[BGB]

On 5/26/2017 7:46 AM, D. Jeff Dionne wrote:
> On May 26, 2017, at 20:50, BGB <cr88192 at gmail.com> wrote:
>> ...not used by GCC in my tests
> It is better to look at the gcc code generator first, to determine what it might emit and what might trigger it to do so, before one assumes anything about what parts of the ISA is does or doesn't use from (I assume) black box compilation tests.   There have been cases over the years where I had assumed gcc would not emit something, only to find that while it is hard to trigger a specific instruction pattern...  it does in fact happen.  Those cases were often related to trying to do odd things with e.g. position independent code.

I was mostly testing with -O3, and with several codebases which used the 
FPU (the largest thus far being Quake);
how I inferred which instructions were going unused was by setting 
breakpoints in the debugger and observing which paths were not being 
triggered.

though, note that I was not arguing that they "should be" dropped; only 
that some of them were omitted, for example, in SH2A.


though, as-is, my emu should have pretty much complete support for the 
SH4 FPU (nevermind holes/issues in my ISA specs, and some parts being 
mostly untested).

similarly as-is, my extended ISA will probably need the full SH4 FPU for 
the full FPU mode (though, still allowing for cores which have a more 
limited FPU).


> Those vector ops and MAC instructions were the ones I was thinking about a few mails ago, in the context of signal processing.  C is often not great at inferring things (to use a term I usually associate with hardware synthesis) like these vector ops, especially for a code generator like sh4 where the user and developer base is limited.   We really need to get someone to maintain that stuff.   Hitachi/Renesas has Code Sorcery doing some of that, there may be work that wasn't merged somewhere, along the lines of the GDB patches that people have been trying to get upstream.

dunno there.


here is the "gcc -v" for the GCC build I am using:
Configured with: 
/mnt/e/bgb.apps4/misc/jcore/aboriginal-1.4.5/build/temp-sh4/gcc-core/configure 
--target=sh-superh-linux 
--prefix=/mnt/e/bgb.apps4/misc/jcore/aboriginal-1.4.5/build/simple-cross-compiler-sh4 
--disable-multilib --disable-nls --enable-c99 --enable-long-long 
--enable-__cxa_atexit --enable-languages=c,c++ --disable-libstdcxx-pch 
--program-prefix=sh4- --disable-threads --disable-shared 
--host=x86_64-walrus-linux
Thread model: single
gcc version 4.2.1


> Now, BGB, if we could just find a way to integrate your efforts into the J-Core project so that the work advances the project's cause, instead of going off on a completely different path ;^}

well, that could be the hard part.

I went off and was working independently as it seems my efforts were at 
odds in some areas with the project's goals.

I wanted to experiment with a few things, but to test ISA features would 
need a compiler which supports them, and the prospect of working on GCC 
was a bit intimidating.


I figured, while I couldn't make a great compiler, I could probably at 
least make "something that works" and "generates mostly passable code". 
past experiences generally give a rough estimate of the time and effort 
required (though, things are made a bit slower by having going to class 
eating up a big chunk of my time).