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

D. Jeff Dionne Jeff at SE-Instruments.com
Fri May 26 05:01:31 EDT 2017


On May 26, 2017, at 16:31, Francisco Javier Bizcocho AntĂșnez <volkovdablo at gmail.com> wrote:
> 
> Hello all,
> BGB could you describe a bit more which instructions from SH4 FPU were not used by C compiler?.

I'm not sure what BGB's compiler does with the FPU, but basically either GCC or libgcc.a / libm.a likely needs to have the option to use basically all of the SH3 and later FPU instructions in order to achieve the best possible floating point performance.   SH4 also has some vector instructions, which are useful for things like signal processing, which likely are not easy for a new compiler to use..

> Also I have another question related with the J2 cores. Do you guys think is possible to exchange the SH2 cores present in the Sega Saturn for to FPGAs with J2 cores on them?.

Yes.

> This is due of the lack of JTAG capabilities of the original SH2 cores, I want to test if I could use this configuration to develop some software that could run later on retail Sega Saturn machines.

exchange in circuit is a bit hard, you likely want to emulate large parts (basically building a functional equivalent) in FPGA.   There was great interest in doing this by some of the original engineers here in Japan, but the project never seems to have gotten off the ground (building products for customers with J2 has been a priority).

> 
> Regards,
> Javier.
> 
>> On 26 May 2017 at 02:18, BGB <cr88192 at gmail.com> wrote:
>>> On 5/25/2017 9:59 AM, D. Jeff Dionne wrote:
>>> This https://antime.kapsi.fi/sega/files/h12p0.pdf is probably the best of the legacy Hitachi documentation to look at.  Look specifically at Appendix A starting pg 251 for the encodings, and the table in section A.4 was dropped from later versions.  That table points possible ways to most efficient decoding.
>>> 
>>> Each of the instructions are also explained in detail (except CAS.L, which is new).  We expect J2 to be a compatible superset, and should test as such (anything else is a bug).  However, J-Core pipeline is a different implementation than any SH, so the instruction timings are also different.  J2 also has separate instruction and data busses, SH2 doesn't.  J2 has a single register file write back port, SH has multiple (likely 2, at least logical) write back ports.  Etc.
>>> 
>> 
>> my case:
>> I referenced the various PDFs, and also wrote my own sets of documentation for personal reference (though errors may exist, and there are various subtle differences between SH2 and SH4, ...); and my documentation is far from comprehensive or complete.
>> 
>> unlike the original documentation, mine mostly rewrote everything in a modified hexadecimal notation:
>> * 0..9, A..F: matches hexadecimal notation.
>> * m, n: normal Rm, Rn register use.
>> * M, N: for a few cases where N or M were limited to being R0..R7 in the 8..F range.
>> * d: displacement (signed or unsigned depending on context)
>> * i: immediate (usually signed)
>> * j: unsigned immediate
>> * ...
>> 
>> mostly this was because I found this form more readable than the binary notation, which seemed mostly unneeded given nearly everything is aligned on nybbles. another difference was I organized things by their location in opcode-space rather than organizing     things based on mnemonic. it isn't strictly lexicographic order though mostly given some specifics about how opcodes are organized.
>> 
>> ex: "1110 nnnn iiii iiii" would be expressed in my notation as "Enii", but other than this, expresses the same instruction.
>> 
>> 
>> from what I can tell (inferred mostly from spec contents), things developed sort of like:
>> * SH1 -> SH2
>> * SH2 -> SH3, SH-DSP
>> * SH3 -> SH4
>> * SH4 -> SH5, SH4A
>> * SH2, SH-DSP, SH4A -> SH2A
>> 
>> SH-DSP was sort of a bit weird in that it added a lot of stuff which doesn't exist in other SH ISAs, and is basically incompatible (ex: with SH4 or friends) as most of its opcode space was reclaimed and repurposed (for example, for the FPU instructions).
>> 
>> for SH3, I lack any real documentation, but can only really infer about what it looked like based on the other SH variants.
>> 
>> for SH4, parts of the FPU were unused by C compilers and were largely dropped from later ISAs.
>> 
>> there is typically a fair amount of variation regarding system level facilities, such as boot-up state or interrupt handling behavior (or which exact registers exist).
>> 
>> 
>> SH5 added a 64-bit ISA, effectively as a separate ISA from the 32-bit ISA.
>> 
>> another possible route is to do a 64-bit ISA as a more conservative extension of the existing ISA.
>> 
>> 
>> there is also SH2A, for which probably its most notable feature is the addition of some instructions which use a 32-bit extended instruction-forms (or I-forms). it seems to derive from several different branches in the ISA, and is harder to nail down if it "directly" derives from one of its predecessors (and notably diverges in some areas).
>> 
>> 
>> I have my own SH variant (currently mostly independent of J-Core; and emu only for a limited subset), which mostly adds some features (at present, its implementation mostly limited to some additional MOV I-forms and similar). its core mostly derives from SH4, and aims towards being backwards compatible.
>> 
>> major additions thus far:
>>     borrows some of SH2A's MOV I-forms (omits most of the rest of 2A);
>>     adds some I-forms that implement signed displacements:
>>         MOV.L @(Rm, disp8s), Rn    //can address +/- 512B from Rm
>>     some which implement scaled-index addressing (similar to x86):
>>         MOV.L @(Rm, Ro, disp8s), Rn    //Rm+(Ro+disp8s)*4
>>     also adds a 'LEA' instruction (also similar to x86), implementing the above addressing modes.
>>         traditionally, LEA is used both in address calc's and also as an arithmetic operator.
>> 
>> previously there were some others, but I recently dropped/collapsed some things (wanted to limit the number of new addressing modes; and realized some of the new I-forms were "kind of stupid"; ...).
>> 
>> thus far, I have currently used 8Axx and 8Exx for 32-bit I-Forms; in addition to the 0xx0, 0xx1, 3xx1, and 3xx9 spaces from 2A (though pretty much no opcodes from 3xx9 are currently used).
>> 
>> also on the "presumably claimed" list (for additional 32-bit I-forms) is FxxF and 82xx.
>> 
>> the spec currently includes a bit more than I have actually implemented, but is intended more for organizing possible ideas than saying how everything would be implemented (and its "viability" is still unproven).
>> 
>> 
>> or such...
>> 
>> 
>>> Cheers,
>>> J
>>> 
>>> On May 25, 2017, at 23:41, Kartik Agaram <ak at akkartik.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm curious what primary documents y'all used in the design of the J-Core architecture and instruction encoding. In particular I'm looking at this link from one of your webpages and wondering if there's a more unpacked/detailed exposition. I did find the book for the SH-4 on Wikipedia. Is there something like that for the SH-2?
>>>> 
>>>> Thanks,
>>>> Kartik
>>>> http://akkartik.name/about
>>>> 
>>>> _______________________________________________
>>>> J-core mailing list
>>>> J-core at lists.j-core.org
>>>> http://lists.j-core.org/mailman/listinfo/j-core
>>> 
>>> 
>>> _______________________________________________
>>> J-core mailing list
>>> J-core at lists.j-core.org
>>> http://lists.j-core.org/mailman/listinfo/j-core
>> 
>> 
>> _______________________________________________
>> J-core mailing list
>> J-core at lists.j-core.org
>> http://lists.j-core.org/mailman/listinfo/j-core
>> 
> 
> _______________________________________________
> J-core mailing list
> J-core at lists.j-core.org
> http://lists.j-core.org/mailman/listinfo/j-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.j-core.org/pipermail/j-core/attachments/20170526/14b3112b/attachment.html>


More information about the J-core mailing list