<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 30.03.2020 um 22:07 schrieb Christo
Crause via fpc-devel:<br>
</div>
<blockquote type="cite"
cite="mid:CAGOmfbGy3JywWEOc0vhOFL9mf-o7emg-X8=hz4fV+nVo5PMnUA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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.<br>
<br>
Regards,<br>
Sven<br>
</body>
</html>