[J-core] Fwd: ISA manual for SH-2
cr88192 at gmail.com
Thu May 25 21:18:41 EDT 2017
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.
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
* 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
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).
> On May 25, 2017, at 23:41, Kartik Agaram <ak at akkartik.com
> <mailto: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 <mailto:J-core at lists.j-core.org>
> J-core mailing list
> J-core at lists.j-core.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J-core