<div dir="ltr"><div dir="ltr">On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>Am 30.03.2020 um 22:07 schrieb Christo
      Crause via fpc-devel:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr"><br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Sun, Mar 29, 2020 at
            11:00 PM Florian Klämpfl <<a href="mailto:florian@freepascal.org" target="_blank">florian@freepascal.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 29.03.20 um 22:46
            schrieb Christo Crause via fpc-devel:<br>
            > It seems that a different instruction sequence should
            be used for sign <br>
            > extension for the lx106 subarch.<br>
             
            <br>
            Ok, I see. Let me first integrate everything done so far in
            trunk, then <br>
            we can continue with the details :)<br>
          </blockquote>
          <div><br>
          </div>
          <div>I've noticed GCC uses the SLLI + SRAI instructions to
            perform sign extension on ESP8266.</div>
          <div><br>
          </div>
          <div>Since different CPUs can support different subsets of the
            Xtensa instructions do you think a finalizecode type
            function can be used as a post code generation step to map
            unsupported instructions to alternative sequences?<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    These are simply different CPU types (-CpXXX or selected by the
    controller type) which the code generator will handle accordingly.
    Just like it's done with ARM, AVR and all other platforms.</div></blockquote><div> </div><div>Make sense. The make files are not current set up like that for xtensa. I'll make a patch to make xtensa-embedded work like avr etc with regards to subarch. This will then make it easier to check for cpu_capabilities in the compiler.<br></div></div></div>