[J-core] Fwd: ISA manual for SH-2
Francisco Javier Bizcocho Antúnez
volkovdablo at gmail.com
Fri May 26 03:31:53 EDT 2017
BGB could you describe a bit more which instructions from SH4 FPU were not
used by C compiler?.
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?. 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
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...
> On May 25, 2017, at 23:41, Kartik Agaram <ak at akkartik.com> wrote:
> 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 <http://www.shared-ptr.com/sh_insns.html> 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?
> J-core mailing list
> J-core at lists.j-core.org
> J-core mailing listJ-core at lists.j-core.orghttp://lists.j-core.org/mailman/listinfo/j-core
> J-core mailing list
> J-core at lists.j-core.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J-core