[J-core] Fwd: ISA manual for SH-2
BGB
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.
>
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
> <mailto: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 <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
>> <http://www.st.com/content/ccc/resource/technical/document/user_manual/69/23/ed/be/9b/ed/44/da/CD00147165.pdf/files/CD00147165.pdf/jcr:content/translations/en.CD00147165.pdf>
>> 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 <mailto: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/20170525/170ed9a9/attachment.html>
More information about the J-core
mailing list