<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 5/25/2017 9:59 AM, D. Jeff Dionne
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7A253C30-CF82-47FC-A094-6662174CCE8F@SE-Instruments.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>This <a href="https://antime.kapsi.fi/sega/files/h12p0.pdf"
moz-do-not-send="true">https://antime.kapsi.fi/sega/files/h12p0.pdf</a> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</blockquote>
<br>
my case:<br>
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.<br>
<br>
unlike the original documentation, mine mostly rewrote everything in
a modified hexadecimal notation:<br>
* 0..9, A..F: matches hexadecimal notation.<br>
* m, n: normal Rm, Rn register use.<br>
* M, N: for a few cases where N or M were limited to being R0..R7 in
the 8..F range.<br>
* d: displacement (signed or unsigned depending on context)<br>
* i: immediate (usually signed)<br>
* j: unsigned immediate<br>
* ...<br>
<br>
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.<br>
<br>
ex: "1110 nnnn iiii iiii" would be expressed in my notation as
"Enii", but other than this, expresses the same instruction.<br>
<br>
<br>
from what I can tell (inferred mostly from spec contents), things
developed sort of like:<br>
* SH1 -> SH2<br>
* SH2 -> SH3, SH-DSP<br>
* SH3 -> SH4<br>
* SH4 -> SH5, SH4A<br>
* SH2, SH-DSP, SH4A -> SH2A<br>
<br>
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).<br>
<br>
for SH3, I lack any real documentation, but can only really infer
about what it looked like based on the other SH variants.<br>
<br>
for SH4, parts of the FPU were unused by C compilers and were
largely dropped from later ISAs.<br>
<br>
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).<br>
<br>
<br>
SH5 added a 64-bit ISA, effectively as a separate ISA from the
32-bit ISA.<br>
<br>
another possible route is to do a 64-bit ISA as a more conservative
extension of the existing ISA.<br>
<br>
<br>
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).<br>
<br>
<br>
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.<br>
<br>
major additions thus far:<br>
borrows some of SH2A's MOV I-forms (omits most of the rest of
2A);<br>
adds some I-forms that implement signed displacements:<br>
MOV.L @(Rm, disp8s), Rn //can address +/- 512B from Rm<br>
some which implement scaled-index addressing (similar to x86):<br>
MOV.L @(Rm, Ro, disp8s), Rn //Rm+(Ro+disp8s)*4<br>
also adds a 'LEA' instruction (also similar to x86),
implementing the above addressing modes.<br>
traditionally, LEA is used both in address calc's and also
as an arithmetic operator.<br>
<br>
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"; ...).<br>
<br>
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).<br>
<br>
also on the "presumably claimed" list (for additional 32-bit
I-forms) is FxxF and 82xx.<br>
<br>
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).<br>
<br>
<br>
or such...<br>
<br>
<br>
<blockquote type="cite"
cite="mid:7A253C30-CF82-47FC-A094-6662174CCE8F@SE-Instruments.com">
<div>
<div>Cheers,
<div>J</div>
</div>
</div>
<div><br>
On May 25, 2017, at 23:41, Kartik Agaram <<a
href="mailto:ak@akkartik.com" moz-do-not-send="true">ak@akkartik.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">Hi,
<div><br>
</div>
<div>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 <a
href="http://www.shared-ptr.com/sh_insns.html"
target="_blank" moz-do-not-send="true">this link</a>
from one of your webpages and wondering if there's a
more unpacked/detailed exposition. I did find <a
href="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"
target="_blank" moz-do-not-send="true">the book for
the SH-4</a> on Wikipedia. Is there something like
that for the SH-2?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Kartik</div>
<div><a href="http://akkartik.name/about"
target="_blank" moz-do-not-send="true">http://akkartik.name/about</a></div>
</div>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>J-core mailing list</span><br>
<span><a href="mailto:J-core@lists.j-core.org"
moz-do-not-send="true">J-core@lists.j-core.org</a></span><br>
<span><a
href="http://lists.j-core.org/mailman/listinfo/j-core"
moz-do-not-send="true">http://lists.j-core.org/mailman/listinfo/j-core</a></span><br>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
J-core mailing list
<a class="moz-txt-link-abbreviated" href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a>
<a class="moz-txt-link-freetext" href="http://lists.j-core.org/mailman/listinfo/j-core">http://lists.j-core.org/mailman/listinfo/j-core</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>