<div dir="ltr"><div dir="ltr">On Wed, Apr 1, 2020 at 12:06 AM Sven Barth <<a href="mailto:pascaldragon@googlemail.com" target="_blank">pascaldragon@googlemail.com</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 dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Christo Crause <<a href="mailto:christo.crause@gmail.com" target="_blank">christo.crause@gmail.com</a>> schrieb am Di., 31. März 2020, 19:45:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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" rel="noreferrer" target="_blank">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></blockquote><div><br></div><div>I directly edited the makefile to demonstrate the principle. In addition to a change to makefile.fpc an update to fpcmake.ini is also required, see attached fpcmake.patch <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><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 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. <br></div></div></blockquote><div><br></div><div>Good idea, the alternative instructions are part of the core ISA so it should always be supported.<br></div></div></div>