Re: [fpc-devel] Error building xtensa rtl
Christo Crause schrieb am Di., 31. März 2020, 19:45: > On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: >> >> 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? >> >> >> 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. >> > > Attach please find a patch to rtl/embedded/MakeFile* to handle subarch > similar to avr and others. > 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 > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.2.0RC1 released!
Am 31.03.20 um 05:55 schrieb Joao Schuler: Just tested with my own neural networks API and I can confirm that it works! Environment: WIN10 64bits AVX Tested with: https://github.com/joaopauloschuler/neural-api/blob/master/examples/SimpleImageClassifier/SimpleImageClassifier.lpr In this test, there is a performance gain (speed) against 3.0.4 at about 9%. Do you have numbers in comparison with trunk? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: > > 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? > > > 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. > 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. diff --git a/rtl/embedded/Makefile b/rtl/embedded/Makefile index 117f0ea026..914e267df4 100644 --- a/rtl/embedded/Makefile +++ b/rtl/embedded/Makefile @@ -197,6 +197,12 @@ $(error When compiling for mipsel-embedded, a sub-architecture (e.g. SUBARCH=pic endif override FPCOPT+=-Cp$(SUBARCH) endif +ifeq ($(FULL_TARGET),xtensa-embedded) +ifeq ($(SUBARCH),) +$(error When compiling for xtensa-embedded, a sub-architecture (e.g. SUBARCH=lx106 or SUBARCH=lx6) must be defined) +endif +override FPCOPT+=-Cp$(SUBARCH) +endif ifneq ($(findstring $(OS_SOURCE),$(LIMIT83fs)),) TARGETSUFFIX=$(OS_TARGET) SOURCESUFFIX=$(OS_SOURCE) @@ -498,8 +504,10 @@ endif endif ifeq ($(ARCH),xtensa) CPU_SPECIFIC_COMMON_UNITS=sysutils math classes fgl macpas typinfo types rtlconsts getopts lineinfo +ifeq ($(SUBARCH),lx106) CPU_UNITS=esp8266 CPU_UNITS_DEFINED=1 +endif ifeq ($(CPU_UNITS_DEFINED),) $(error No CPUs enabled for given SUBARCH, pass either a SUBARCH or set CPU_UNITS_DEFINED=1 if you know what you are doing) endif diff --git a/rtl/embedded/Makefile.fpc b/rtl/embedded/Makefile.fpc index 0566231c3c..ff89dc336c 100644 --- a/rtl/embedded/Makefile.fpc +++ b/rtl/embedded/Makefile.fpc @@ -223,8 +223,10 @@ endif ifeq ($(ARCH),xtensa) CPU_SPECIFIC_COMMON_UNITS=sysutils math classes fgl macpas typinfo types rtlconsts getopts lineinfo +ifeq ($(SUBARCH),lx106) CPU_UNITS=esp8266 CPU_UNITS_DEFINED=1 +endif ifeq ($(CPU_UNITS_DEFINED),) $(error No CPUs enabled for given SUBARCH, pass either a SUBARCH or set CPU_UNITS_DEFINED=1 if you know what you are doing) endif diff --git a/compiler/xtensa/cgcpu.pas b/compiler/xtensa/cgcpu.pas index a1fdbede87..f3e24b7365 100644 --- a/compiler/xtensa/cgcpu.pas +++ b/compiler/xtensa/cgcpu.pas @@ -167,14 +167,28 @@ implementation list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg1,0,8)); OS_S8: begin -list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,7)); +if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then + list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,7)) +else if current_settings.cputype = cpu_lx106 then + begin +list.concat(taicpu.op_reg_reg_const(A_SLLI,reg2,reg1,24)); +list.concat(taicpu.op_reg_reg_const(A_SRAI,reg2,reg2,24)); + end +else + internalerror(2020033101); if tosize=OS_16 then list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg2,0,16)); end; OS_16: list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg1,0,16)); OS_S16: - list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,15)); + if target_info.abi = abi_xtensa_windowed then +list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,15)) + else +begin + list.concat(taicpu.op_reg_reg_const(A_SLLI,reg2,reg1,16)); + list.concat(taicpu.op_reg_reg_const(A_SRAI,reg2,reg2,16)); +end; else conv_done:=false; end; @@ -258,7 +272,15 @@ implementation list.concat(taicpu.op_reg_ref(op,reg,href)); if (fromsize=OS_S8) and not(tosize in [OS_S8,OS_8]) then - list.concat(taicpu.op_reg_reg_const(A_SEXT,reg,reg,7)); + if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then +list.concat(taicpu.op_reg_reg_const(A_SEXT,reg,reg,7)) + else if current_settings.cputype = cpu_lx106 then +begin + list.concat(taicpu.op_reg_reg_const(A_SLLI,reg,reg,24)); +
Re: [fpc-devel] Error building xtensa rtl
On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: > > > On Sun, Mar 29, 2020 at 11:00 PM Florian Klämpfl > wrote: > >> Am 29.03.20 um 22:46 schrieb Christo Crause via fpc-devel: >> > It seems that a different instruction sequence should be used for sign >> > extension for the lx106 subarch. >> >> Ok, I see. Let me first integrate everything done so far in trunk, then >> we can continue with the details :) >> > > 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? > > > 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. > 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Partial compile issues
> Simply clearing all the compiled files results in correct > compilation. Any thoughts on how to proceed with this? Am I the only one > to see this? > > Colin It happens sometimes. Although it happens much less frequent in current trunk. Please report in bugtracker if you have reproducible case. -- Regards, Denis Golovan ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.2.0RC1 released!
That's pretty good! I guess our individual work on the compiler. while maybe giving marginal gains, really accumulate. Gareth aka. Kit On 31/03/2020 04:55, Joao Schuler wrote: Just tested with my own neural networks API and I can confirm that it works! Environment: WIN10 64bits AVX Tested with: https://github.com/joaopauloschuler/neural-api/blob/master/examples/SimpleImageClassifier/SimpleImageClassifier.lpr In this test, there is a performance gain (speed) against 3.0.4 at about 9%. Congrats! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
