<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On May 26, 2017, at 16:31, Francisco Javier Bizcocho AntĂșnez <<a href="mailto:volkovdablo@gmail.com">volkovdablo@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div>Hello all,<br></div>BGB could you describe a bit more which instructions from SH4 FPU were not used by C compiler?.<br></div></div></div></div></div></blockquote><div><br></div><div>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..</div><br><blockquote type="cite"><div><div dir="ltr"><div><div>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?.</div></div></div></div></blockquote><div><br></div><div>Yes.</div><br><blockquote type="cite"><div><div dir="ltr"><div><div> 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.<br></div></div></div></div></blockquote><div><br></div><div>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).</div><br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div>Regards,<br></div>Javier.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 May 2017 at 02:18, BGB <span dir="ltr"><<a href="mailto:cr88192@gmail.com" target="_blank">cr88192@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div class="m_-5806610350994610495moz-cite-prefix">On 5/25/2017 9:59 AM, D. Jeff Dionne
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div>This <a href="https://antime.kapsi.fi/sega/files/h12p0.pdf" target="_blank">https://antime.kapsi.fi/<wbr>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></span>
    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...<span class=""><br>
    <br>
    <br>
    <blockquote type="cite">
      <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" target="_blank">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">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">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">http://akkartik.name/about</a></div>
              </div>
            </div>
            <br>
          </div>
        </div>
      </blockquote>
      <blockquote type="cite">
        <div><span>______________________________<wbr>_________________</span><br>
          <span>J-core mailing list</span><br>
          <span><a href="mailto:J-core@lists.j-core.org" target="_blank">J-core@lists.j-core.org</a></span><br>
          <span><a href="http://lists.j-core.org/mailman/listinfo/j-core" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a></span><br>
        </div>
      </blockquote>
      <br>
      <fieldset class="m_-5806610350994610495mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
J-core mailing list
<a class="m_-5806610350994610495moz-txt-link-abbreviated" href="mailto:J-core@lists.j-core.org" target="_blank">J-core@lists.j-core.org</a>
<a class="m_-5806610350994610495moz-txt-link-freetext" href="http://lists.j-core.org/mailman/listinfo/j-core" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </span></div>

<br>______________________________<wbr>_________________<br>
J-core mailing list<br>
<a href="mailto:J-core@lists.j-core.org">J-core@lists.j-core.org</a><br>
<a href="http://lists.j-core.org/mailman/listinfo/j-core" rel="noreferrer" target="_blank">http://lists.j-core.org/<wbr>mailman/listinfo/j-core</a><br>
<br></blockquote></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">J-core@lists.j-core.org</a></span><br><span><a href="http://lists.j-core.org/mailman/listinfo/j-core">http://lists.j-core.org/mailman/listinfo/j-core</a></span><br></div></blockquote></body></html>