When building the xtensa rtl with

make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CROSSOPT=-Cacall0 CPU_TARGET=xtensa OS_TARGET=embedded SUBARCH=esp8266 BINUTILSPREFIX=xtensa-lx106-elf-

the following errors are returned by as:
/home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler messages:
/home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:203: Error: unknown opcode or format name 'sext'
/home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:204: Error: unknown opcode or format name 'sext'

When building with CROSSOPT=-Cawindowed as complains about other errors: /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler messages:
/home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:11: Error: unknown opcode or format name 'retw'

Any tips on how to build the xtensa rtl?

I didn't care about the call0 abi yet. Is it used by the esp8266?

Inspecting some C examples I've compiled with PlatformIO for ESP8266 shows use of callx0 for the non-rtos SDK. My goal was just to test the cross compiler, but the RTL failed with error 2020031404 (in tcpuparamanager.init_values) which seems to suggest an ABI must be specified. Neither of the options I tried satisfied the assembler however.

According to the Xtensa ISA 4.3.8 the SEXT instruction is optional (and some others too) and apparently not implemented for ESP8266 according to core-isa.h in ESP8266_RTOS_SDK (
https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/components/esp8266/include/xtensa/config/core-isa.h). This explains why xtensa-lx106-elf-as does not recognise the SEXT instruction.

It seems that a different instruction sequence should be used for sign extension for the lx106 subarch.

Also core-isa.h indicates XCHAL_HAVE_WINDOWED = 0, which I take to mean that the LX106 toolchain doesn't know/implement the windowed ABI, which explains why setting the FPC ABI to windowed caused as to flag retw as unknown.

Ok, I see. Let me first integrate everything done so far in trunk, then we can continue with the details :)

Also core-isa.h indicates XCHAL_HAVE_WINDOWED = 0, which I take to mean that the LX106 toolchain doesn't know/implement the windowed ABI, which explains why setting the FPC ABI to windowed caused as to flag retw as unknown.

I've noticed GCC uses the SLLI + SRAI instructions to perform sign extension on ESP8266.

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?

In this case just cgcpu can be adapted to generate the right code. This results normally in better code.

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.

Regards,
Sven

On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel <

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.

On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel <

Attach please find a patch to rtl/embedded/MakeFile* to handle subarch similar to avr and others.
Also attached a patch that checks whether the SEXT instruction is available for the current subarchitecture, else it generates SLLI + SRAI combination.

I post the patches here for review since I'm not sure this is necessarily the style to be followed when checking capabilities.

Christo Crause schrieb am Di., 31. März 2020,
19:45:

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.

Also attached a patch that checks whether the SEXT instruction is available

for the current subarchitecture, else it generates SLLI + SRAI combination.

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.

Regards,
Sven

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

Good idea, the alternative instructions are part of the core ISA so it should always be supported.

PM Christo Crause wrote

Good idea, the alternative instructions are part of the core ISA so it should always be supported.

So the updated cgcpu patch attached...

Christo Crause wrote

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

I committed the SUBARCH changes.

doesn't it make sense to also include subarchs in xtensa-freertos?

diff --git a/utils/fpcm/fpcmake.ini b/utils/fpcm/fpcmake.ini index 16396ca921..9151c09021 100644
--- a/utils/fpcm/fpcmake.ini
+++ b/utils/fpcm/fpcmake.ini
@@ -295,6 +295,13 @@ endif
 override FPCOPT+=-Cp$(SUBARCH)
 endif

+ifeq ($(FULL_TARGET),xtensa-freertos)
+ifeq ($(SUBARCH),)
+$(error When compiling for xtensa-freertos, a sub-architecture (e.g. SUBARCH=lx106 or SUBARCH=lx6) must be defined)
+endif
+override FPCOPT+=-Cp$(SUBARCH)
+endif
+