<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Christo Crause <<a href="mailto:christo.crause@gmail.com">christo.crause@gmail.com</a>> schrieb am Di., 31. März 2020, 19:45:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank" rel="noreferrer">fpc-devel@lists.freepascal.org</a>> wrote:<br><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"><div class="gmail_quote"><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.<br>
</div></blockquote><div><br></div><div>Attach please find a patch to rtl/embedded/MakeFile* to handle subarch similar to avr and others.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Did you manually edit the Makefile or regenerate it from the Makefile.fpc? If the former then your changes at the top will be overwritten by the next makefile regeneration. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Also attached a patch that checks whether the SEXT instruction is available for the current subarchitecture, else it generates SLLI + SRAI combination.</div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If SLLI and SRAI are supported by the other processors supported by FPC then you don't need to check for the processor type, checking against the capability for SEXT is enough. If some processor does not support SLLI or SRAI either then this would need to be a capability as well. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>