[fpc-devel] SUBARCH's revisited, need some help for installing packages in a SUBARCH directory
Hi! Christo has done some magic on the esp32 targets and together we are currently trying to make everything available in an as consistent as possible way. One thing that is very necessary from my point of view is that we properly support SUBARCH's when building rtl and packages as there are linker errors when an incompatible rtl is used for linking. We never finished discussions on arm and avr targets, perhaps now is a good time to finalize the discussions and to apply the results to the esp32 targets as a start. Until now we resorted to manually specify INSTALL_UNITDIR on installation but when the problem is properly addressed then also fpc.cfg can be changed accordingly to include the required directories in the search paths and things should work out of the box for every developer that wishes to build a cross-compiler from source. I have now made this (kind of) work but I am still a bit unshure where the absolute best place is to make my changes and yes, there's a very crude hack involved While changes to make SUBARCH directories for RTL are pretty straightforward things look different for packages because they use fpmake and the switch from Makefiles to fpmake seems to cause issues that are hard to understand/debug for me The whole thing currently only works with this crude hack in the Makefile in the packages directory, at that point INSTALL_BASEDIR is not yet defined so I need to build the path to the proper location manually: @@ -14,6 +14,14 @@ fpcdir=.. [prerules] # Translate INSTALL_UNITDIR to fpmake's --unitinstalldir parameter +ifndef INSTALL_UNITDIR +ifeq ($(CPU_OS_TARGET),xtensa-freertos) +INSTALL_UNITDIR=$(INSTALL_PREFIX)/lib/fpc/$(FPC_VERSION)/units/$(TARGETSUFFIX)/$(SUBARCH) +endif +ifeq ($(CPU_OS_TARGET),riscv32-freertos) +INSTALL_UNITDIR=$(INSTALL_PREFIX)/lib/fpc/$(FPC_VERSION)/units/$(TARGETSUFFIX)/$(SUBARCH) +endif +endif ifdef INSTALL_UNITDIR FPMAKE_INSTALL_OPT+=--unitinstalldir=$(INSTALL_UNITDIR) endif to get this: ./fpmake install --localunitdir=.. --os=freertos --cpu=riscv32 -o -Cprv32imc -o -Tfreertos -o -Priscv32 -o -XPriscv32-freertos- -o -Ur -o -Xs -o -O2 -o -n -o -driscv32 -o -dRELEASE --compiler=/Users/tgdrimi9/devel/fpc-esp32/compiler/ppcrossrv32 -bu -scp --prefix=/Users/tgdrimi9/devel/fpc-esp32/test --baseinstalldir=/Users/tgdrimi9/devel/fpc-esp32/test/lib/fpc/3.3.1 --unitinstalldir=/Users/tgdrimi9/devel/fpc-esp32/test/lib/fpc/3.3.1/units/riscv32-freertos/rv32imc for some reason unknown to me the following code (some lines deeper in the Makefiles) does not work, the unitinstalldir is not set when fpmake is called... ifndef INSTALL_UNITDIR +ifeq ($(CPU_OS_TARGET),xtensa-freertos) +INSTALL_UNITDIR:=$(INSTALL_BASEDIR)/units/$(TARGETSUFFIX)/$(SUBARCH) +ifdef INSTALL_FPCPACKAGE +ifdef PACKAGE_NAME +INSTALL_UNITDIR:=$(INSTALL_UNITDIR)/$(PACKAGE_NAME) +FPMAKE_INSTALL_OPT+=--unitinstalldir=$(INSTALL_UNITDIR) +endif +endif +endif +endif +ifndef INSTALL_UNITDIR +ifeq ($(CPU_OS_TARGET),riscv32-freertos) INSTALL_UNITDIR:=$(INSTALL_BASEDIR)/units/$(TARGETSUFFIX)/$(SUBARCH) ifdef INSTALL_FPCPACKAGE ifdef PACKAGE_NAME INSTALL_UNITDIR:=$(INSTALL_UNITDIR)/$(PACKAGE_NAME) besides this there is another issue, the units are not put in their subdirectories, they are all put in the lib/fpc/3.3.1/units/riscv32-freertos/rv32imc directory. Any help apprechiated, let me know when you need more info, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Raspberry Pi Pico: Heapsize is initialized with wrong value
PR:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/638
Am 01.04.24 um 22:33 schrieb Michael Ring via fpc-devel:
I am using heapmgr but with trunk compiler the value of __heapsize is
plain wrong (and way too big)
When I compile my code with my old compiler for pico all is fine, when
I debug into heapmgr I see that __heapsize is set correctly to 16384
based on this setting:
program spi_st7789;
{$MODE OBJFPC}
{$H+}
{$MEMORY 16384,16384}
When I use current main compiler the value is 308528 which is more
than available memory, this is why I found the issue
The reason for this is that a line from my original code for
linkerfile generation was not included:
Add(' *(.data .data.*)');
// Special Section for the Raspberry Pico, needed for linking to spi
* Add(' *(.time_critical*)');
* Add(' KEEP (*(.fpc .fpc.n_version .fpc.n_links))');
Add(' _edata = .;');
and for that reason the content of that section in loaded to start of
flash (and during startup to ram) instead of the correct data for
__heapsize
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Raspberry Pi Pico: Heapsize is initialized with wrong value
I am using heapmgr but with trunk compiler the value of __heapsize is
plain wrong (and way too big)
When I compile my code with my old compiler for pico all is fine, when I
debug into heapmgr I see that __heapsize is set correctly to 16384 based
on this setting:
program spi_st7789;
{$MODE OBJFPC}
{$H+}
{$MEMORY 16384,16384}
When I use current main compiler the value is 308528 which is more than
available memory, this is why I found the issue
The reason for this is that a line from my original code for linkerfile
generation was not included:
Add(' *(.data .data.*)');
// Special Section for the Raspberry Pico, needed for linking to spi
* Add(' *(.time_critical*)');
* Add(' KEEP (*(.fpc .fpc.n_version .fpc.n_links))');
Add(' _edata = .;');
and for that reason the content of that section in loaded to start of
flash (and during startup to ram) instead of the correct data for __heapsize
Was there a reason for leaving this out when my code was merged to main?
I guess no, so I will create a PR to fix this issue, please comment when
there was a reason for leaving this out.
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unaligned access on Cortex-M0 in Initialization code
Works, thank you!
Michael
Am 31.03.24 um 22:18 schrieb Florian Klämpfl via fpc-devel:
Am 31.03.2024 um 21:58 schrieb Michael Ring via fpc-devel
:
This is what I see (guess the same thing):
New Compiler:
FPC_INITIALIZE:
.Lc3882:
# path: /Users/ring/devel/fpc/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10741:
push {r4,r5,r14}
...
ldr r0,[r0, r1]
mov r15,r0
.La5:
.long .Lj13323
My last commit should fix it.
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unaligned access on Cortex-M0 in Initialization code
As a workaround I compiled rtl with -Oonopeephole and verified that the
balign is there, looking good!
Should I open an issue on gitlab or will you take care?
Many thanks and have a nice rest of Easter holidays,
Michael
Am 31.03.24 um 21:58 schrieb Michael Ring via fpc-devel:
This is what I see (guess the same thing):
New Compiler:
FPC_INITIALIZE:
.Lc3882:
# path: /Users/ring/devel/fpc/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10741:
push {r4,r5,r14}
...
ldr r0,[r0, r1]
mov r15,r0
.La5:
.long .Lj13323
Old Compiler (2 years old):
FPC_INITIALIZE:
.Lc3594:
# path: /Users/ring/devel/freepascal-sources/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10488:
push {r4,r5,r14}
...
mov r15,r0
* .balign 4*
.La5:
.long .Lj12924
Am 31.03.24 um 21:50 schrieb Florian Klämpfl via fpc-devel:
Am 31.03.2024 um 21:35 schrieb Florian Klämpfl via fpc-devel
:
Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel
:
Hi,
it has been a while since I have been deep,deep down in the rabbit
hole of Cortex Assembly, so please forgive me if I am overlooking
something...
I have an application for Raspberry Pico (target embedded) and it
fails during initialization as soon as I add a unit that includes
an object and I reference the object in my code...
In that case fpc_initialize (for rtti?) is called and I cannot find
source code for fpc_initialize
In the debugger I see that R0 is $1000177E and R1 is $28 This is in
the flash area, so far, so good but $1000177E is obviously not word
alligned, it is halfword aligned so this then triggers
_HardFault_Handler.
10001778 4648 ldr r0, [pc, #280] ;
(0x10001894 )
1000177A 4058 ldr r0, [r0, r1] ;
Crash Boom Bang !
Looking at the map file the address is within fpc_initialize, but
as I cannot find the proper source I am a bit lost...
.text.n_fpc_initialize
0x10001758 0x144
/Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o
0x10001758 fpc_initialize
0x10001758 FPC_INITIALIZE
.text.n_fpc_finalize
0x1000189c 0x164
/Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o
Any help appreciated,
Can you post some more context? fpc_initalize is not that big so it
should be possible to identify where this comes from.
Ok, I think I found it, it is one for Gareth:
var
i : longint;
begin
case i of
1: writeln(1);
2: writeln(2);
3: writeln(2);
4: writeln(2);
5: writeln(2);
end;
end.
ppcarm -Cparmv6m -al -O2 t.pp -Tlinux -Oonopeephole
results in:
...
subr1,#1
lslr1,r1,#2
ldrr0,.Lj11
ldrr0,[r0, r1]
movr15,r0
.balign 4
.La1:
.long.Lj4
.long.Lj5
.long.Lj6
.long.Lj7
.long.Lj8
…
The peephole removes the alignment before case jump tables: if no
-Oonopeephole is passed, the .balign 4 is gone.
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unaligned access on Cortex-M0 in Initialization code
This is what I see (guess the same thing):
New Compiler:
FPC_INITIALIZE:
.Lc3882:
# path: /Users/ring/devel/fpc/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10741:
push {r4,r5,r14}
...
ldr r0,[r0, r1]
mov r15,r0
.La5:
.long .Lj13323
Old Compiler (2 years old):
FPC_INITIALIZE:
.Lc3594:
# path: /Users/ring/devel/freepascal-sources/rtl/inc/
# file: rtti.inc
# indx: 19
.Ll10488:
push {r4,r5,r14}
...
mov r15,r0
* .balign 4*
.La5:
.long .Lj12924
Am 31.03.24 um 21:50 schrieb Florian Klämpfl via fpc-devel:
Am 31.03.2024 um 21:35 schrieb Florian Klämpfl via fpc-devel
:
Am 31.03.2024 um 17:11 schrieb Michael Ring via fpc-devel
:
Hi,
it has been a while since I have been deep,deep down in the rabbit
hole of Cortex Assembly, so please forgive me if I am overlooking
something...
I have an application for Raspberry Pico (target embedded) and it
fails during initialization as soon as I add a unit that includes an
object and I reference the object in my code...
In that case fpc_initialize (for rtti?) is called and I cannot find
source code for fpc_initialize
In the debugger I see that R0 is $1000177E and R1 is $28 This is in
the flash area, so far, so good but $1000177E is obviously not word
alligned, it is halfword aligned so this then triggers
_HardFault_Handler.
10001778 4648 ldr r0, [pc, #280] ;
(0x10001894 )
1000177A 4058 ldr r0, [r0, r1] ;
Crash Boom Bang !
Looking at the map file the address is within fpc_initialize, but as
I cannot find the proper source I am a bit lost...
.text.n_fpc_initialize
0x10001758 0x144
/Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o
0x10001758 fpc_initialize
0x10001758 FPC_INITIALIZE
.text.n_fpc_finalize
0x1000189c 0x164
/Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o
Any help appreciated,
Can you post some more context? fpc_initalize is not that big so it
should be possible to identify where this comes from.
Ok, I think I found it, it is one for Gareth:
var
i : longint;
begin
case i of
1: writeln(1);
2: writeln(2);
3: writeln(2);
4: writeln(2);
5: writeln(2);
end;
end.
ppcarm -Cparmv6m -al -O2 t.pp -Tlinux -Oonopeephole
results in:
...
subr1,#1
lslr1,r1,#2
ldrr0,.Lj11
ldrr0,[r0, r1]
movr15,r0
.balign 4
.La1:
.long.Lj4
.long.Lj5
.long.Lj6
.long.Lj7
.long.Lj8
…
The peephole removes the alignment before case jump tables: if no
-Oonopeephole is passed, the .balign 4 is gone.
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Unaligned access on Cortex-M0 in Initialization code
Hi, it has been a while since I have been deep,deep down in the rabbit hole of Cortex Assembly, so please forgive me if I am overlooking something... I have an application for Raspberry Pico (target embedded) and it fails during initialization as soon as I add a unit that includes an object and I reference the object in my code... In that case fpc_initialize (for rtti?) is called and I cannot find source code for fpc_initialize In the debugger I see that R0 is $1000177E and R1 is $28 This is in the flash area, so far, so good but $1000177E is obviously not word alligned, it is halfword aligned so this then triggers _HardFault_Handler. 10001778 4648 ldr r0, [pc, #280] ; (0x10001894 ) 1000177A 4058 ldr r0, [r0, r1] ; Crash Boom Bang ! Looking at the map file the address is within fpc_initialize, but as I cannot find the proper source I am a bit lost... .text.n_fpc_initialize 0x10001758 0x144 /Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o 0x10001758 fpc_initialize 0x10001758 FPC_INITIALIZE .text.n_fpc_finalize 0x1000189c 0x164 /Users/tgdrimi9/fpcupdeluxe/fpc/units/arm-embedded/armv6m/eabi/rtl/system.o Any help appreciated, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] How to show Linker Errors when compiling embedded targets?
There's a small issue when compiling code for embedded, when there is a linker error for unresolved externals it does not get displayed. example: ~/fpcupdeluxe/lazarus/lazbuild -B pio_ws2812-raspi_pico.lpi using config file /Users/ring/fpcupdeluxe/lazarus/lazarus.cfg pio_ws2812.lpr(85) Error: (9013) Error while linking pio_ws2812.lpr(85) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted Error: /Users/ring/fpcupdeluxe/fpc/bin/aarch64-darwin/ppcarm returned an error exitcode Error: (lazarus) Compile Project, OS: embedded, CPU: arm, Target: bin/pio_ws2812.elf: stopped with exit code 1 Error: (lazbuild) failed compiling of project /Users/ring/devel/pico-fpcexamples/pio_ws2812/pio_ws2812-raspi_pico.lpi problem seems to be that stdout is not displayed by the DoExec / sysutils.ExecuteProcess on my Mac so the details on linker error get lost. To find the error the code then has to be compiled with -sh parameter and after running ppas.sh the error surfaces: ./ppas.sh Assembling pico_c ... Linking /Users/ring/devel/pico-fpcexamples/pio_ws2812/bin/pio_ws2812 /Users/ring/fpcupdeluxe/cross/bin/arm-embedded/arm-none-eabi-ld: /Users/ring/devel/pico-fpcexamples/units/pio.c.obj: in function `pio_add_program': pio.c:(.text.pio_add_program+0xd2): undefined reference to `panic' An error occurred while linking /Users/ring/devel/pico-fpcexamples/pio_ws2812/bin/pio_ws2812 I followed the code in t_embed responsible for linking and tried using process unit but it is not known to the compiler itself. Is there a variant of DoExec or something else that can be used in the compiler to run the link command again in case of an error so that the linker error gets displayed? Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Public access of FPC features and settings
Florian, it seems you missed a comment on that topic I wrote a while ago. There is also the need to have a tuple that matches controllertype to controllerunit to get rid of a big peace of duplicated code from cpuinfo.pas in lazarus. Lazarus needs to know which unit to include so that codetools can do their magic. In current implementation parts of controllertypes are duplicated in lazarus code. To get rid of this lazarus will not only need to know the available controllertypes, it will also need to have the mapping from controllertype tu unitname like this: * * in the xml. Example: ~/fpcupdeluxe-test/fpc/bin/aarch64-darwin/fpc -Tembedded -Parm -ix ... ... ... ... ... ... ... ... *...* * ** *... ... FPC Am 02.04.21 um 15:07 schrieb Michael Van Canneyt via fpc-devel: On Fri, 2 Apr 2021, Florian Klämpfl via fpc-devel wrote: Am 07.03.2021 um 15:12 schrieb Florian Klämpfl via fpc-devel : Am 07.03.21 um 12:05 schrieb Alfred via fpc-devel: Hello, As a follow-up on a Lazarus feature request. Among other applications, Lazarus uses some hard-coded list that represent FPC features. Like supported MCU and boards. It would be (much) more convenient to parse the FPC output itself to supply this info. And that could be made easy by using XML as FPC output. Besides the above, I would welcome more features to be available through FPC itself. FPC uses system files, located in "compiler/systems". With all kinds of settings. Like alignment and calling convention and linker to use. FPC uses search-paths. Some user defined through fpc.cfg, some build-in. See all -F... compiler settings. It would be nice to be able to get info through FPC itself about these settings and paths. As maintainer of fpcupdeluxe, often I need to parse fpc.cfg by hand. Or look into a file like fpmkunit.pp to find the valid FPC targets. Or parse the Makefile to find all available subarchs when building a cross-compiler. For a start, I would favor a XML/JSON output of fpc -i. Would be very nice to use its output. I added a first experimental implementation in r48897. It does not cover full -i, so far only to show how it could look like. Any comments? Meanwhile I completed it. So if somebody thinks it’s useful, the json output can be added as well. Will do, thanks! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Public access of FPC features and settings
for this command: ~/fpcupdeluxe-embedded/fpc/bin/aarch64-darwin/fpc -Tembedded -Parm -WpDISCOVERYF411VE -ix it would be good to also get back the controllerunitstr that belongs to DISCOVERYF411VE or, when size does not matter much include the unit already in the more generalized call: ~/fpcupdeluxe-embedded/fpc/bin/aarch64-darwin/fpc -Tembedded -Parm -ix Michael Am 07.03.21 um 15:12 schrieb Florian Klämpfl via fpc-devel: Am 07.03.21 um 12:05 schrieb Alfred via fpc-devel: Hello, As a follow-up on a Lazarus feature request. Among other applications, Lazarus uses some hard-coded list that represent FPC features. Like supported MCU and boards. It would be (much) more convenient to parse the FPC output itself to supply this info. And that could be made easy by using XML as FPC output. Besides the above, I would welcome more features to be available through FPC itself. FPC uses system files, located in "compiler/systems". With all kinds of settings. Like alignment and calling convention and linker to use. FPC uses search-paths. Some user defined through fpc.cfg, some build-in. See all -F... compiler settings. It would be nice to be able to get info through FPC itself about these settings and paths. As maintainer of fpcupdeluxe, often I need to parse fpc.cfg by hand. Or look into a file like fpmkunit.pp to find the valid FPC targets. Or parse the Makefile to find all available subarchs when building a cross-compiler. For a start, I would favor a XML/JSON output of fpc -i. Would be very nice to use its output. I added a first experimental implementation in r48897. It does not cover full -i, so far only to show how it could look like. Any comments? fpc -ix writes to the console fpc -ixfpc_info.xml to fpc_info.xml ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos
the lm4f120 was the only unit that did not fit. funny enough it was already defined for armv7em so this patch only removes it from armv7m diff --git a/rtl/embedded/Makefile b/rtl/embedded/Makefile index 1b39161b56..e3242e2a2b 100644 --- a/rtl/embedded/Makefile +++ b/rtl/embedded/Makefile @@ -374,7 +374,7 @@ CPU_SPECIFIC_COMMON_UNITS= ifeq ($(ARCH),arm) CPU_SPECIFIC_COMMON_UNITS=sysutils math classes fgl macpas typinfo types rtlconsts getopts lineinfo ifeq ($(SUBARCH),armv7m) -CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 lm4f120 sam3x8e xmc4500 cortexm3 cortexm4 # thumb2_bare +CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 sam3x8e xmc4500 cortexm3 cortexm4 # thumb2_bare CPU_UNITS_DEFINED=1 endif ifeq ($(SUBARCH),armv7em) diff --git a/rtl/embedded/Makefile.fpc b/rtl/embedded/Makefile.fpc index ff89dc336c..8817d786bd 100644 --- a/rtl/embedded/Makefile.fpc +++ b/rtl/embedded/Makefile.fpc @@ -71,7 +71,7 @@ CPU_SPECIFIC_COMMON_UNITS= ifeq ($(ARCH),arm) CPU_SPECIFIC_COMMON_UNITS=sysutils math classes fgl macpas typinfo types rtlconsts getopts lineinfo ifeq ($(SUBARCH),armv7m) -CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 lm4f120 sam3x8e xmc4500 cortexm3 cortexm4 # thumb2_bare +CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 sam3x8e xmc4500 cortexm3 cortexm4 # thumb2_bare CPU_UNITS_DEFINED=1 endif ifeq ($(SUBARCH),armv7em) Am 20.02.21 um 22:26 schrieb Michael Ring via fpc-devel: lm4f120: yes, it should be moved in the makefile. But let me dig a little big, perhaps there are more files that are wrong, will come back to you. Michael Am 20.02.21 um 21:51 schrieb Florian Klämpfl via fpc-devel: Am 20.02.21 um 10:35 schrieb Michael Ring via fpc-devel: I have created an issue with this patch for ermbedded target, for unknown reason the 'end;' at the end of the patch for rtl/embedded/arm/cortexm4f_start.inc is missing, likely when I copy/pasted I lost that line. Sorry for this I committed it. Will there in the future be a way to provide pull-requests via github (or does this already work??) I guess that would reduce the likelyhood of such a stupid error.. Most likely yes, however, so far nobody really found the time for the switch to git. And then I also found another small mishap in rtl/freertos/arm/cortexm4f_start.inc, there a 'not' was left over after you changed the logic for fpu detection. When Investigating I saw that lm4f120 is built as armv7m but is actually armv7em (plus it uses m4f include). Not sure if it is woth fixing a seven years old file, so I left things as they are. This doesn't matter imo, it should be fixed. So you mean just moving it to another subarch in the makefile? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos
lm4f120: yes, it should be moved in the makefile. But let me dig a little big, perhaps there are more files that are wrong, will come back to you. Michael Am 20.02.21 um 21:51 schrieb Florian Klämpfl via fpc-devel: Am 20.02.21 um 10:35 schrieb Michael Ring via fpc-devel: I have created an issue with this patch for ermbedded target, for unknown reason the 'end;' at the end of the patch for rtl/embedded/arm/cortexm4f_start.inc is missing, likely when I copy/pasted I lost that line. Sorry for this I committed it. Will there in the future be a way to provide pull-requests via github (or does this already work??) I guess that would reduce the likelyhood of such a stupid error.. Most likely yes, however, so far nobody really found the time for the switch to git. And then I also found another small mishap in rtl/freertos/arm/cortexm4f_start.inc, there a 'not' was left over after you changed the logic for fpu detection. When Investigating I saw that lm4f120 is built as armv7m but is actually armv7em (plus it uses m4f include). Not sure if it is woth fixing a seven years old file, so I left things as they are. This doesn't matter imo, it should be fixed. So you mean just moving it to another subarch in the makefile? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos
I have created an issue with this patch for ermbedded target, for
unknown reason the 'end;' at the end of the patch for
rtl/embedded/arm/cortexm4f_start.inc is missing, likely when I
copy/pasted I lost that line. Sorry for this
Will there in the future be a way to provide pull-requests via github
(or does this already work??) I guess that would reduce the likelyhood
of such a stupid error..
And then I also found another small mishap in
rtl/freertos/arm/cortexm4f_start.inc, there a 'not' was left over after
you changed the logic for fpu detection.
When Investigating I saw that lm4f120 is built as armv7m but is actually
armv7em (plus it uses m4f include). Not sure if it is woth fixing a
seven years old file, so I left things as they are.
Michael
diff --git a/rtl/embedded/arm/cortexm4f_start.inc
b/rtl/embedded/arm/cortexm4f_start.inc
index dc2928c70a..62017d9834 100644
--- a/rtl/embedded/arm/cortexm4f_start.inc
+++ b/rtl/embedded/arm/cortexm4f_start.inc
@@ -74,3 +74,4 @@ asm
.Ltext_start:
.long _text_start
{$endif REMAP_VECTTAB}
+end;
diff --git a/rtl/freertos/arm/cortexm4f_start.inc
b/rtl/freertos/arm/cortexm4f_start.inc
index 756aeb994a..62017d9834 100644
--- a/rtl/freertos/arm/cortexm4f_start.inc
+++ b/rtl/freertos/arm/cortexm4f_start.inc
@@ -64,7 +64,7 @@ asm
.long _data
.L_edata:
.long _edata
-{$if not defined(FPUARM_HAS_VFP_EXTENSION)}
+{$if defined(FPUARM_HAS_VFP_EXTENSION)}
.Lcpacr:
.long 0xE000ED88
{$endif defined(FPUARM_HAS_VFP_EXTENSION)}
Am 19.02.21 um 22:13 schrieb Michael Ring via fpc-devel:
You are the best, thank you!
Michael
Am 19.02.21 um 22:11 schrieb Florian Klämpfl via fpc-devel:
Am 19.02.21 um 21:55 schrieb Michael Ring via fpc-devel:
When rtl for arm-embedded/arm-freertos is build with hardfloat the
fpu should also automagically get enabled, by default it is off
which causes a crash when floats are used.
This small patch fixes that problem in cortexm4f_start.inc
can you please apply this patch to trunk?
Thanks, I applied it in a modified form so the presence of an vfp
unit is checked, this should be more future and fool proof :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos
You are the best, thank you! Michael Am 19.02.21 um 22:11 schrieb Florian Klämpfl via fpc-devel: Am 19.02.21 um 21:55 schrieb Michael Ring via fpc-devel: When rtl for arm-embedded/arm-freertos is build with hardfloat the fpu should also automagically get enabled, by default it is off which causes a crash when floats are used. This small patch fixes that problem in cortexm4f_start.inc can you please apply this patch to trunk? Thanks, I applied it in a modified form so the presence of an vfp unit is checked, this should be more future and fool proof :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Enabling hardware floating point processor for cortex-m4f on embedded and freertos
When rtl for arm-embedded/arm-freertos is build with hardfloat the fpu
should also automagically get enabled, by default it is off which causes
a crash when floats are used.
This small patch fixes that problem in cortexm4f_start.inc
can you please apply this patch to trunk?
Thank you,
Michael
diff --git a/rtl/embedded/arm/cortexm4f_start.inc
b/rtl/embedded/arm/cortexm4f_start.inc
index 82202b1565..fa557becfc 100644
--- a/rtl/embedded/arm/cortexm4f_start.inc
+++ b/rtl/embedded/arm/cortexm4f_start.inc
@@ -43,6 +43,14 @@ asm
str r1, [r0]
{$endif REMAP_VECTTAB}
+{$if not defined(FPUSOFT)}
+ ldr r0, .Lcpacr
+ ldr r1, [r0]
+ orr r1, r1, #0xf0
+ str r1, [r0]
+ dsb
+ isb
+{$endif not defined(FPUSOFT)}
bl PASCALMAIN
b HaltProc
@@ -56,10 +64,13 @@ asm
.long _data
.L_edata:
.long _edata
+{$if not defined(FPUSOFT)}
+.Lcpacr:
+ .long 0xE000ED88
+{$endif not defined(FPUSOFT)}
{$ifdef REMAP_VECTTAB}
.Lvtor:
.long 0xE000ED08
.Ltext_start:
.long _text_start
{$endif REMAP_VECTTAB}
-end;
\ No newline at end of file
diff --git a/rtl/freertos/arm/cortexm4f_start.inc
b/rtl/freertos/arm/cortexm4f_start.inc
index 82202b1565..70b75ee6ae 100644
--- a/rtl/freertos/arm/cortexm4f_start.inc
+++ b/rtl/freertos/arm/cortexm4f_start.inc
@@ -43,6 +43,14 @@ asm
str r1, [r0]
{$endif REMAP_VECTTAB}
+{$if not defined(FPUSOFT)}
+ ldr r0, .Lcpacr
+ ldr r1, [r0]
+ orr r1, r1, #0xf0
+ str r1, [r0]
+ dsb
+ isb
+{$endif not defined(FPUSOFT)}
bl PASCALMAIN
b HaltProc
@@ -56,10 +64,14 @@ asm
.long _data
.L_edata:
.long _edata
+{$if not defined(FPUSOFT)}
+.Lcpacr:
+ .long 0xE000ED88
+{$endif not defined(FPUSOFT)}
{$ifdef REMAP_VECTTAB}
.Lvtor:
.long 0xE000ED08
.Ltext_start:
.long _text_start
{$endif REMAP_VECTTAB}
-end;
\ No newline at end of file
+end;
diff --git a/rtl/embedded/arm/cortexm4f_start.inc
b/rtl/embedded/arm/cortexm4f_start.inc
index 82202b1565..fa557becfc 100644
--- a/rtl/embedded/arm/cortexm4f_start.inc
+++ b/rtl/embedded/arm/cortexm4f_start.inc
@@ -43,6 +43,14 @@ asm
str r1, [r0]
{$endif REMAP_VECTTAB}
+{$if not defined(FPUSOFT)}
+ ldr r0, .Lcpacr
+ ldr r1, [r0]
+ orr r1, r1, #0xf0
+ str r1, [r0]
+ dsb
+ isb
+{$endif not defined(FPUSOFT)}
bl PASCALMAIN
b HaltProc
@@ -56,10 +64,13 @@ asm
.long _data
.L_edata:
.long _edata
+{$if not defined(FPUSOFT)}
+.Lcpacr:
+ .long 0xE000ED88
+{$endif not defined(FPUSOFT)}
{$ifdef REMAP_VECTTAB}
.Lvtor:
.long 0xE000ED08
.Ltext_start:
.long _text_start
{$endif REMAP_VECTTAB}
-end;
\ No newline at end of file
diff --git a/rtl/freertos/arm/cortexm4f_start.inc
b/rtl/freertos/arm/cortexm4f_start.inc
index 82202b1565..70b75ee6ae 100644
--- a/rtl/freertos/arm/cortexm4f_start.inc
+++ b/rtl/freertos/arm/cortexm4f_start.inc
@@ -43,6 +43,14 @@ asm
str r1, [r0]
{$endif REMAP_VECTTAB}
+{$if not defined(FPUSOFT)}
+ ldr r0, .Lcpacr
+ ldr r1, [r0]
+ orr r1, r1, #0xf0
+ str r1, [r0]
+ dsb
+ isb
+{$endif not defined(FPUSOFT)}
bl PASCALMAIN
b HaltProc
@@ -56,10 +64,14 @@ asm
.long _data
.L_edata:
.long _edata
+{$if not defined(FPUSOFT)}
+.Lcpacr:
+ .long 0xE000ED88
+{$endif not defined(FPUSOFT)}
{$ifdef REMAP_VECTTAB}
.Lvtor:
.long 0xE000ED08
.Ltext_start:
.long _text_start
{$endif REMAP_VECTTAB}
-end;
\ No newline at end of file
+end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What is the status of -CfLIBGCC ? Can ib be considered good/working for embedded targets?
Thanks, so I will try to have some fun with debugging softfp, 'fortuately' the first issue manifested itself in multiplying two numbers, may the gods of gdb smile on me! Michael Am 14.02.2021 um 14:19 schrieb Florian Klämpfl via fpc-devel: Am 14.02.21 um 14:08 schrieb Michael Ring via fpc-devel: I am having a lot of (no-)fun with floating point on Cortex-M0, current summary would be to say that things get pretty unreliable once I start using Floats. I today stumbled over -CfLIBGCC, sounds interesting, but compiling cross-compiler trunk with this option ends up in an error: /Library/Developer/CommandLineTools/usr/bin/make -C embedded all /Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/ppcarm -Cparmv6m -Ur -Tembedded -Parm -XParm-none-eabi- -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FD/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin -FE. -FU/Users/ring/devel/freepascal/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap -Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -darm -dRELEASE -O1 -g -Cflibgcc -Us -Sg system.pp @system.cfg system.inc(426,5) Fatal: Internal error 200312126 Fatal: Compilation aborted Is the option worth asking for a fix so that it compiles again or is it anyway so experimental that I better try to find the issues within softfp? libgcc was never really usable on any target. softfpu works very well on most targets, so it is most likely a simple armv6m issue. I propose we hunt the armv6m issue down, it is probably just a simple cg issue which surfaces by the softfloat code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] What is the status of -CfLIBGCC ? Can ib be considered good/working for embedded targets?
I am having a lot of (no-)fun with floating point on Cortex-M0, current summary would be to say that things get pretty unreliable once I start using Floats. I today stumbled over -CfLIBGCC, sounds interesting, but compiling cross-compiler trunk with this option ends up in an error: /Library/Developer/CommandLineTools/usr/bin/make -C embedded all /Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/ppcarm -Cparmv6m -Ur -Tembedded -Parm -XParm-none-eabi- -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FD/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin -FE. -FU/Users/ring/devel/freepascal/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap -Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -darm -dRELEASE -O1 -g -Cflibgcc -Us -Sg system.pp @system.cfg system.inc(426,5) Fatal: Internal error 200312126 Fatal: Compilation aborted Is the option worth asking for a fix so that it compiles again or is it anyway so experimental that I better try to find the issues within softfp? Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revision 48628 (* do not initialize unncessary register allocators ) breaks build of RTL for armv7m and armv7em
Code now compiles again, thank you for fixing! Michael Am 13.02.21 um 17:11 schrieb Michael Ring via fpc-devel: I just updated to latest trunk and found out that armv7m and armv7em RTL does not build anymore: /Library/Developer/CommandLineTools/usr/bin/make -C rtl all /Library/Developer/CommandLineTools/usr/bin/make -C embedded all /Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7m -Ur -Tembedded -Parm -XParm-none-eabi- -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE. -FU/Users/ring/devel/fpc.svn/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap -Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -darm -dRELEASE -Us -Sg system.pp @system.cfg softfpu.pp(586,1) Error: Compilation raised exception internally Fatal: Compilation aborted An unhandled exception occurred at $000101503B3A: EAccessViolation: Access violation $000101503B3A ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Revision 48628 (* do not initialize unncessary register allocators ) breaks build of RTL for armv7m and armv7em
I just updated to latest trunk and found out that armv7m and armv7em RTL does not build anymore: /Library/Developer/CommandLineTools/usr/bin/make -C rtl all /Library/Developer/CommandLineTools/usr/bin/make -C embedded all /Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7m -Ur -Tembedded -Parm -XParm-none-eabi- -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE. -FU/Users/ring/devel/fpc.svn/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap -Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -darm -dRELEASE -Us -Sg system.pp @system.cfg softfpu.pp(586,1) Error: Compilation raised exception internally Fatal: Compilation aborted An unhandled exception occurred at $000101503B3A: EAccessViolation: Access violation $000101503B3A ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Making $FPCABI work as expected for embedded targets
There is an issue with compiling code for armv7em, we may compile with hardfloat support or without. The compiled files are link-incompatible as ABI is different so mixing them is a bad thing. I played arround with $FPCABI in fpc.cfg but found out that it is always set to 'default' because the parameter -Ca is not parsed on firstpass and fpc.cfg is evaluated immediately after firstpass and for that reason my entries that contain '$FPCABI' get discarded. I use those entries in fpc.cfg: -Fu/Users/ring/fpcupdeluxe-embedded/fpc/units/arm-embedded/$FPCSUBARCH/$FPCABI/rtl -Fu/Users/ring/fpcupdeluxe-embedded/fpc/units/arm-embedded/$FPCSUBARCH/$FPCABI/packages To solve this I have made -Ca a first-pass option: diff --git a/compiler/options.pas b/compiler/options.pas index 4bf2bf35f5..c410d9d4b0 100644 --- a/compiler/options.pas +++ b/compiler/options.pas @@ -1118,6 +1118,7 @@ begin ((length(opt)>1) and (opt[2] in ['i','d','v','T','u','n','X','l','U'])) or ((length(opt)>3) and (opt[2]='F') and (opt[3]='e')) or ((length(opt)>3) and (opt[2]='C') and (opt[3]='p')) or + ((length(opt)>3) and (opt[2]='C') and (opt[3]='a')) or ((length(opt)>3) and (opt[2]='W') and (opt[3] in ['m','p'])) ) ) then and now evaluation of $FPCABI seems to work just fine. But as I am not that deep in the internals of FPC the question is if my change makes sense or if sonner or later my cat will explode or my Mac will suddenly convert to run Windows... or some other harmfull things will happen with making Ca firstpass. If this causes no issue, can this please be applied to trunk to make $FPCABI actually work? Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Latest trunk - problems with codesign on MacOSX
Thank you, building from within fpcupdeluxe now works Am 13.02.21 um 09:20 schrieb Jonas Maebe via fpc-devel: On 12/02/2021 11:33, Michael Ring via fpc-devel wrote: So, question one is if it is necessary to detect codesign path at all, at least for my Mac's it is in /usr/bin It may not exist at all, e.g. on PowerPC Macs. and, if this step is needed, please make the result of the detection unique so that codesign stops trying to codesign itself. Fixed. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Latest trunk - problems with codesign on MacOSX
In a recent trunk version new code was introduced in the compiler Makefile to make use of codesign for comparing stage compilers. Problem is that there was an algorithm implemented to detect codesign in the path and this code is not properly covering the case when for some reason codesign is visible in two places... (Which happens for me when I try to use fpcupdeluxe to build latest trunk) Here's the magic code: ifeq ($(OS_TARGET), darwin) CODESIGN?=$(strip $(wildcard $(addsuffix /codesign,$(SEARCHPATH endif I have added debug output and there can be cases where $CODESIGN is set to "/usr/bin/codesign /usr/bin/codesign" which results in codesign trying to sign codesign, which fortunately fails because of /usr/bin protection in Darwin: /Library/Developer/CommandLineTools/usr/bin/make -C compiler distclean $CODESIGN is [/usr/bin/codesign /usr/bin/codesign] . error: /Library/Developer/CommandLineTools/usr/bin/codesign_allocate: can't create output file: /usr/bin/codesign.cstemp (Operation not permitted) and finally, later the build fails: strip -no_uuid ppca64.tmp /usr/bin/codesign /usr/bin/codesign --remove-signature ppc3.tmp there is also another issue: ifneq ($(CODESIGN),) DIFFRESULT:=$(shell $(COPY) $(OLDFPC) $(OLDFPC).tmp; $(COPY) $(FPC) $(FPC).tmp; strip -no_uuid $(OLDFPC).tmp; strip -no_uuid $(FPC).tmp; $(CODESIGN) --remove-signature $(OLDFPC).tmp; *codesign* --remove-signature $(FPC).tmp; $(DIFF) $(OLDFPC).tmp $(FPC).tmp; $(RMPROG) $(OLDFPC).tmp $(FPC).tmp) One instance of 'codesign' is still left in the code which has to get replaced with $(CODESIGN) So, question one is if it is necessary to detect codesign path at all, at least for my Mac's it is in /usr/bin and, if this step is needed, please make the result of the detection unique so that codesign stops trying to codesign itself. Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Two floating point issues for the price of one on Cortex-M0 / Trunk
Jeppe already told me that floating point could be a little shaky on
Cortex-M, and he was right...
I am creating examples for the Raspberry Pi Pico and the ADC example
requires some floating point math.
All testing was done with trunk version of fpc from today
RTL was compiled with empty CROSSOPTS options, for details please see
end of text.
The first issue smells a lot like an optimization issue, when I compile
rtl with -O- then it is gone.
First issue is about mutiplication/division.
The same code run with single datatype creates (wrong) negative result
for this multiplication:
rawvalue := 887;
value := rawvalue*3.3/(1 shl 12);
The 2nd one is a bit more strange, here I am asking myself if I forgot
something:
str(value:6:3,valuestr);
When I compile the code with double my string version of the number is
prefixed by 10 or so spaces.
when I compile with single datatype output of str is fine, no spaces as
prefix.
When I comment out the three codelines behind the str command and
compile with double I get correct transformation without the prefixed
spaces.
When I compile RTL with -O- then double shows correctly and single is
prefixed with spaces.
Commandline to compile code:
fpc -Tembedded -Parm -Cparmv6m -godwarfsets -godwarfcpp
-Wp-WpNUCLEOG071RB floatmult.lpr
(I compile here for NUCLEOG071RB as Raspberry Pico is not yet in trunk)
Sample Code:
program floatmult;
{$MODE OBJFPC}
{$H-}
var
//value : single; // gives -0.715 in line 11+12
value : double; // gives 0.715 in line 11+12
rawvalue : longWord;
valuestr : string;
begin
rawvalue := 887;
value := rawvalue*3.3/(1 shl 12);
str(value:6:3,valuestr);
//value := value - 0.706;
//value := value / 0.001721;
//value := 27 - value;
end.
Building fpc RTL for armv6m
+ make --directory=/Users/ring/devel/fpc FPCDIR=/Users/ring/devel/fpc
FPCMAKE=/Users/ring/devel/fpc/utils/fpcm/fpcmake
PPUMOVE=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/ppumove
INSTALL_PREFIX=/Users/ring/fpcupdeluxe-embedded/fpc
INSTALL_BINDIR=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin
CROSSBINDIR=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin
FPC=/Users/ring/fpcupdeluxe-embedded/fpc/bin/x86_64-darwin/ppcarm
rtl_clean rtl_all CROSSINSTALL=1 CPU_SOURCE=x86_64 OS_SOURCE=darwin
OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv6m NOGDBMI=1
BINUTILSPREFIX=arm-none-eabi- 'OPT=-vw-n-h-l-d-u-t-p-c- -ap
-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib'
CROSSOPT=
INSTALL_UNITDIR=/Users/ring/fpcupdeluxe-embedded/fpc/units/arm-embedded/armv6m/rtl
+ pv '--name=Build ' --line-mode --size 50
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Need your help on how to best fix cmsis incompatibilities between arm chip vendors when linking to c-code
I am having an issue in the form that I want to link to freertos static
library and I do not want to provide a freertos library for every
flavour of interrupt vector tables that is out there. (and there are
quite some...)
Also, there are people who want to link to vendor specific arduino
libraries that include already full implementation for gpio, spi, i2c
and whatever and those libs also use the vendor specific naming. for the
system interrupts defined by cmsis standard.
In a perfect world we would only have one freertos static lib for
armv6m, one for armv7m and one for armv7em that uses cmsis compatible names.
But there are vendors that name, for example, the scvcall handler
svc_handler, some call it svcall_handler and last version I saw was with
new rp2040 chip, they totally ignore everything and name the handler
isr_svcall.
In FreeRTOS the problem is solved by defining the right name to use for
svcall handler in a header file and then recompiling FreeRTOS for your
specific vendor.
In Freepascal we could do the same thing but this would require us to
either provide all flavours of freertos as a static library or to
require the user to build a freertos lib on their own that matches the
name for svc handler that is defined within fpc unit for the chip
needed. Not very userfriendly
So I was thinking about a workarround which I seem to have found, we can
redefine Linker symbols as needed in the gnu linker with the --defsym=
parameter.
I have attached below sample code that shows how this works.
My problem is now that I do not know how to best implement this in
freepascal so that it is as transparent as possible to the user, not
requiring him to create a huge list of defsym parameters in the lpi file
or on commandline.
My current idea is to put a list of default defsyms for arm chips in
t_embed/t_freertos, re-mapping non-cmsis conformant names to proper
cmsis names.
Does this make sense to you guys or does it sound like a crazy hack? I
am not sure myself so I would love to hear your opinion, or perhaps even
better ideas on how to solve the problem
Thanks in advance,
Michael
Example:
program svctest;
uses
svchandlers;
procedure handle_svc external name 'handle_svc';
begin
handle_svc;
end.
unit svchandlers;
interface
procedure isr_svcall; public name 'isr_svcall';
procedure svcall_handler; public name 'svcall_handler';
procedure svc_handler; public name 'svc_handler';
implementation
procedure isr_svcall;
begin
writeln('I am isr_svcall');
end;
procedure svcall_handler;
begin
writeln('I am svcall_handler');
end;
procedure svc_handler;
begin
writeln('I am svc_handler');
end;
end.
Now compile like this:
fpc -Parm -Tembedded -Wpbluepill -Cparmv7m
-k'--defsym=handle_svc=svc_handler' svctest.pas
fpc -Parm -Tembedded -Wpbluepill -Cparmv7m
-k'--defsym=handle_svc=svcall_handler' svctest.pas
fpc -Parm -Tembedded -Wpbluepill -Cparmv7m
-k'--defsym=handle_svc=isr_svcall' svctest.pas
one of the three implementations will be choosen based on the selected
defsym
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Creating uf2 files for arm-embedded and Raspberry Pi Pico
No need to change the comment, does not matter to me Thanks for applying the patch, Florian! Michael Am 24.01.21 um 18:05 schrieb Christo Crause via fpc-devel: On Sat, Jan 23, 2021 at 12:07 AM Florian Klämpfl via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> wrote: Am 22.01.21 um 22:02 schrieb Michael Ring via fpc-devel: > Are you guys willing to accept that patch in fpc trunk? Yes. The commit message for r48394 should rather acknowledge Michael Ring as patch submitter ;-) Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch for uf2 support in freePascal
I am sorry but my last comment wasn't meant for the list, I wanted to
send it directly to Florian but I failed miserably
But for the main question raised in the (german) mail it makes perhaps
sense to translate it to english...
In Cortex Startup files the relocation of the VectorTable is put inside
an {$ifdef REMAP_VECTTAB} which makes it necessary to define this in
virtually every controller unit to be able to use bootloaders. Question
is why this was done in that way.
I now can already partially self-answer myself, to date It looks like
when I did something on Cortex-M0 I used cortex-m0+ based controllers
and for those the vtor register existed. However is an optional feature
(Although an often implemented one for M0+).
On CortexM3 and higher chips it is always implemented. Only Cortex-M0
seems to be the big exception to the rule. But why this relocation is
not enabled by default in M3 and M4F Header files is still something I
do not understand.
Michael
Am 23.01.21 um 05:17 schrieb J. Gareth Moreton via fpc-devel:
I hope this isn't too much to ask, but if this IS intended for this
mailing list, would someone be willing to translate for me? I'm still
learning German (I assume it's German) and am not good enough yet to
make much sense of this.
Gareth aka. Kit
On 22/01/2021 22:37, Michael Ring via fpc-devel wrote:
Hi Florian, im Anhang der Path für den UF2 Support in freepascal, ich
hoffe er passt so für Dich...
Das UF2 File wird nur erzeugt wenn die Startadresse ungleich
$ ist da normalerweise der UF2 Bootloader ab Addresse 0 steht
und es damit keinen sinnmacht ein uf2 file zu erzeugen wenn die
Startaddresse auf default für Arm steht da dann der uf2 loader mit
dem eigentlichen code kollidiert.
Der Fall das eine Startadresse via -Ttext angepasst wird ist auch mit
drin, habe ich noch was vergessen?
Für den vollen Support muss auch noch das vtor Register umgeschrieben
werden damit man interrupt-Handler im eigenen Code definieren kann,
ich habe dazu bei mir den Startup Code for cortex M0,M3,M4F
angepasst, keine Ahnung warum dieser Teil in dem {$ifdef
REMAP_VECTTAB} define steht, denn dies muss dann in jeder Unit für
einen Controller gesetzt werden obwohl bei den default Einstellungen
der Remap korrekt ist.
Hast Du eine Ahnung warum das so gemacht wurde?
Ist nur ein Detail, wenn ich in der unit für den Raspi Pico den wert
definiere dann wird vtor ja richtig gesetzt.
Michael
Mein Startup Code:
ldr r0, .Lvtor
ldr r1, .Ltext_start
str r1, [r0]
bl PASCALMAIN
b HaltProc
.balign 4
.L_bss_start:
.long _bss_start
.L_bss_end:
.long _bss_end
.L_etext:
.long _etext
.L_data:
.long _data
.L_edata:
.long _edata
.Lvtor:
.long 0xE000ED08
statt original startup Code:
{$ifdef REMAP_VECTTAB}
ldr r0, .Lvtor
ldr r1, .Ltext_start
str r1, [r0]
{$endif REMAP_VECTTAB}
bl PASCALMAIN
b HaltProc
.L_bss_start:
.long _bss_start
.L_bss_end:
.long _bss_end
.L_etext:
.long _etext
.L_data:
.long _data
.L_edata:
.long _edata
{$ifdef REMAP_VECTTAB}
.Lvtor:
.long 0xE000ED08
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Patch for uf2 support in freePascal
Hi Florian, im Anhang der Path für den UF2 Support in freepascal, ich
hoffe er passt so für Dich...
Das UF2 File wird nur erzeugt wenn die Startadresse ungleich $
ist da normalerweise der UF2 Bootloader ab Addresse 0 steht und es damit
keinen sinnmacht ein uf2 file zu erzeugen wenn die Startaddresse auf
default für Arm steht da dann der uf2 loader mit dem eigentlichen code
kollidiert.
Der Fall das eine Startadresse via -Ttext angepasst wird ist auch mit
drin, habe ich noch was vergessen?
Für den vollen Support muss auch noch das vtor Register umgeschrieben
werden damit man interrupt-Handler im eigenen Code definieren kann, ich
habe dazu bei mir den Startup Code for cortex M0,M3,M4F angepasst, keine
Ahnung warum dieser Teil in dem {$ifdef REMAP_VECTTAB} define steht,
denn dies muss dann in jeder Unit für einen Controller gesetzt werden
obwohl bei den default Einstellungen der Remap korrekt ist.
Hast Du eine Ahnung warum das so gemacht wurde?
Ist nur ein Detail, wenn ich in der unit für den Raspi Pico den wert
definiere dann wird vtor ja richtig gesetzt.
Michael
Mein Startup Code:
ldr r0, .Lvtor
ldr r1, .Ltext_start
str r1, [r0]
bl PASCALMAIN
b HaltProc
.balign 4
.L_bss_start:
.long _bss_start
.L_bss_end:
.long _bss_end
.L_etext:
.long _etext
.L_data:
.long _data
.L_edata:
.long _edata
.Lvtor:
.long 0xE000ED08
statt original startup Code:
{$ifdef REMAP_VECTTAB}
ldr r0, .Lvtor
ldr r1, .Ltext_start
str r1, [r0]
{$endif REMAP_VECTTAB}
bl PASCALMAIN
b HaltProc
.L_bss_start:
.long _bss_start
.L_bss_end:
.long _bss_end
.L_etext:
.long _etext
.L_data:
.long _data
.L_edata:
.long _edata
{$ifdef REMAP_VECTTAB}
.Lvtor:
.long 0xE000ED08
diff --git a/compiler/systems/t_embed.pas b/compiler/systems/t_embed.pas
index 1b6d8d0065..c52fb4903e 100644
--- a/compiler/systems/t_embed.pas
+++ b/compiler/systems/t_embed.pas
@@ -39,6 +39,7 @@ implementation
TlinkerEmbedded=class(texternallinker)
private
Function WriteResponseFile: Boolean;
+ Function GenerateUF2(binFile,uf2File : string;baseAddress :
longWord):boolean;
public
constructor Create; override;
procedure SetDefaultInfo; override;
@@ -2847,6 +2848,10 @@ begin
success:=DoExec(FindUtil(utilsprefix+'objcopy'),'-O binary '+
FixedExeFileName+' '+
maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.bin'))),true,false);
+if success then
+ success :=
GenerateUF2(maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.bin'))),
+
maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.uf2'))),
+
embedded_controllers[current_settings.controllertype].flashbase);
{$ifdef ARM}
if success and (current_settings.controllertype = ct_raspi2) then
success:=DoExec(FindUtil(utilsprefix+'objcopy'),'-O binary '+
FixedExeFileName + ' kernel7.img',true,false);
@@ -2863,6 +2868,105 @@ function TLinkerEmbedded.postprocessexecutable(const fn
: string;isdll:boolean):
end;
+function TlinkerEmbedded.GenerateUF2(binFile,uf2File : string;baseAddress :
longWord):boolean;
+type
+ TFamilies= record
+k : String;
+v : longWord;
+ end;
+ tuf2Block = record
+magicStart0,
+magicStart1,
+flags,
+targetAddr,
+payloadSize,
+blockNo,
+numBlocks,
+familyid : longWord;
+data : array[0..255] of byte;
+padding : array[0..511-256-32-4] of byte;
+magicEnd : longWord;
+ end;
+
+const
+ Families : array of TFamilies = (
+(k:'SAMD21'; v:$68ed2b88),
+(k:'SAML21'; v:$1851780a),
+(k:'SAMD51'; v:$55114460),
+(k:'NRF52'; v:$1b57745f),
+(k:'STM32F0';v:$647824b6),
+(k:'STM32F1';v:$5ee21072),
+(k:'STM32F2';v:$5d1a0a2e),
+(k:'STM32F3';v:$6b846188),
+(k:'STM32F4';v:$57755a57),
+(k:'STM32F7';v:$53b80f00),
+(k:'STM32G0';v:$300f5633),
+(k:'STM32G4';v:$4c71240a),
+(k:'STM32H7';v:$6db66082),
+(k:'STM32L0';v:$202e3a91),
+(k:'STM32L1';v:$1e1f432d),
+(k:'STM32L4';v:$00ff6919),
+(k:'STM32L5';v:$04240bdf),
+(k:'STM32WB';v:$70d16653),
+(k:'STM32WL';v:$21460ff0)
+ );
+
+var
+ f,g : file;
+ uf2block : Tuf2Block;
+ totalRead,numRead : longWord;
+ familyId,i : longWord;
+ ExtraOptions : String;
+
+begin
+ if pos('-Ttext=',Info.ExtraOptions) > 0 then
+ begin
+ExtraOptions :=
copy(Info.ExtraOptions,pos('-Ttext=',Info.ExtraOptions)+7,length(Info.ExtraOptions));
+for i := 1 to length(ExtraOptions) do
+ if pos(copy(ExtraOptions,i,1),'0123456789abcdefxABCDEFX') = 0 then
+ExtraOptions := copy(ExtraOptions,1,i);
+baseAddress := StrToIntDef(ExtraOptions,0);
+ end;
+
+ familyId := 0;
+ for i := 0 to length(Families)-1 do
+ begin
+if
pos(Families[i].k,embedded_controllers[current_settings.controllertype].controllerunitstr)
= 1 then
+
[fpc-devel] Creating uf2 files for arm-embedded and Raspberry Pi Pico
Hi! Raspberry Pi organization announced the Raspberry Pi Pico (A dualcore Cortex-M0) and by coincidence I played with uf2 file format in the past days which is used by this board and many, many Adafruit boards to upload firmware in an easy way. So as a first step in the direction of supporting the new raspberry board I can offer a small extension to fpc that creates an uf2 file in the link step of arm-embedded. Are you guys willing to accept that patch in fpc trunk? Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur
Hi Jonas, thank you for your answer! I cannot say if I did see a warning or not when installing fpc-package but I did not reinstall commandline tools before or after installing the 3.2.0 compiler. They have been on all of my Macs for years. What are you doing in the installer that creates that dependency? My guess would be that you rewrite /etc/fpc.cfg (I think I saw on one of my Macs that the timestamp of that file changed), but this will not help for compiling the compiler as the compiler is beeing compiled with the flag -n which effectively turns off reading /etc/fpc.cfg. I made compilation work by adding an OPT parameter to the build: make clean all OPT="-Fl$(xcrun --show-sdk-path)/usr/lib -Ff$(xcrun --show-sdk-path)/System/Library/Frameworks" or, without using $(): make clean all OPT="-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -Ff/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks" So I guess the best solution would be to change the compiler Makefiles to add the Fl/Ff parameter to the compile when on a Mac. I am currently investigating this, what do you think, could that solve the issue once and for all? (We have already had this kind of conversation several times over the last years, usually on crt1.o Fixing the Makefile will make this work for already existing compilers, I'd still propose to add this path from within fpc, when the linker commands are generated. Or am I missing something ? I am updating now my older Mac that is still on Catalina to latest XCode, will be interesting to see how this computer behaves after the update, with older xcode installed I can do 'make clean all' without any issue... I can also run my build command there, on this machine XCode is installed so the Path to CommandlineTools points to some other place, but things still seems to work fine. Michael Am 14.11.20 um 15:10 schrieb Jonas Maebe: On 2020-11-14 11:03, Michael Ring via fpc-devel wrote: I recently upgraded to Big Sur on two devices and tried to compile trunk based on official 3.2.0 compiler freshly downloaded from sourceforge but compilation fails: That looks like you did not install the Xcode command line tools *before* installing FPC. The installer should warn you about this if it detects that is the case. Previous FPC versions refused to install at all in this case, but I changed it into a warning because Apple kept changing things that broke this detection. It should function correctly on macOS 11.0/Big Sur though. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur
Problem is more simple, path to SDK tools is missing in linker script: -arch x86_64 -macosx_version_min 10.8 -L/usr/lib/ -L./x86_64/ -L./systems/ -L/Users/ring/devel/fpc/rtl/units/x86_64-darwin/ -L./x86/ -L/usr/local/bin/ *-L/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/* -lc A permanent solution could be to add a call to xcrun to the link process to make sure (hopefully once and for all) that the SDK path is set in the linker-script: ring@MacBook-Pro-1 compiler $ xcrun --show-sdk-path (master)fpc /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk ring@MacBook-Pro-1 compiler $ ls -l /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk (master)fpc lrwxr-xr-x 1 root wheel 15 10 Dez 2019 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -> MacOSX10.15.sdk shall I try to create a patch? Michael Am 14.11.20 um 11:03 schrieb Michael Ring via fpc-devel: I recently upgraded to Big Sur on two devices and tried to compile trunk based on official 3.2.0 compiler freshly downloaded from sourceforge but compilation fails: make all /usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ring/devel/fpc/rtl/units/x86_64-darwin -Fix86_64 -FEx86_64/bin/x86_64-darwin -FUx86_64/units/x86_64-darwin -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Fix86 pp.pas ld: library not found for -lc An error occurred while linking pp.pas(280,36) Error: Error while linking pp.pas(280,36) Fatal: There were 1 errors compiling module, stopping Same thing happens when trying to compile from within fpcupdeluxe, Developer Tools are installed and up to date. This may be related to a change in MacOS Big Sur, found a few comments on the possible issue: https://github.com/dotnet/msbuild/issues/5454 there it says: This will stop working in the next version of macOS: New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to |dlopen()| the path, which will correctly check for the library in the cache. (62986286) In Linker script -lc is last entry: ring@MacBook-Pro-1 x86_64-darwin $ cat link.res -arch x86_64 -macosx_version_min 10.8 -L/usr/lib/ -L./x86_64/ -L./systems/ -L/Users/ring/devel/fpc/rtl/units/x86_64-darwin/ -L./x86/ -L/usr/local/bin/ -lc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Issue with Compiling FPC and MacOS Big Sur
I recently upgraded to Big Sur on two devices and tried to compile trunk based on official 3.2.0 compiler freshly downloaded from sourceforge but compilation fails: make all /usr/local/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/Users/ring/devel/fpc/rtl/units/x86_64-darwin -Fix86_64 -FEx86_64/bin/x86_64-darwin -FUx86_64/units/x86_64-darwin -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Fix86 pp.pas ld: library not found for -lc An error occurred while linking pp.pas(280,36) Error: Error while linking pp.pas(280,36) Fatal: There were 1 errors compiling module, stopping Same thing happens when trying to compile from within fpcupdeluxe, Developer Tools are installed and up to date. This may be related to a change in MacOS Big Sur, found a few comments on the possible issue: https://github.com/dotnet/msbuild/issues/5454 there it says: This will stop working in the next version of macOS: New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to |dlopen()| the path, which will correctly check for the library in the cache. (62986286) In Linker script -lc is last entry: ring@MacBook-Pro-1 x86_64-darwin $ cat link.res -arch x86_64 -macosx_version_min 10.8 -L/usr/lib/ -L./x86_64/ -L./systems/ -L/Users/ring/devel/fpc/rtl/units/x86_64-darwin/ -L./x86/ -L/usr/local/bin/ -lc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revision 45973 breaks build for arm-embedded target on my Mac
Compile works fine again, thanks again! Michael Am 01.08.20 um 19:27 schrieb Sven Barth via fpc-devel: Am 01.08.2020 um 13:36 schrieb Michael Ring via fpc-devel: Null problemo, thanks for the update! Should be fixed in r45981. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revision 45973 breaks build for arm-embedded target on my Mac
Null problemo, thanks for the update! Michael Am 01.08.20 um 13:32 schrieb Sven Barth via fpc-devel: Michael Ring via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Sa., 1. Aug. 2020, 13:26: Revision 45972 builds fine, all Revisions since 45973 create this error on my Mac. I checked with armv6m, armv7m and armv7em subarchs: It's already on my list, though I can't fix it *right now* as I have an appointment. For now use an earlier revision, please. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Revision 45973 breaks build for arm-embedded target on my Mac
Revision 45972 builds fine, all Revisions since 45973 create this error on my Mac. I checked with armv6m, armv7m and armv7em subarchs: /Applications/Xcode.app/Contents/Developer/usr/bin/make -C rtl all /Applications/Xcode.app/Contents/Developer/usr/bin/make -C embedded all /Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv6m -Ur -Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE. -FU/Users/ring/devel/fpc-svn/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap -darm -dRELEASE -Us -Sg system.pp @system.cfg system.pp(264,10) Error: Overloaded functions have the same parameter list system.inc(704,10) Error: Found declaration: Random(LongInt):LongInt; system.inc(712,10) Error: Found declaration: Random(Int64):Int64; system.inc(747,10) Error: Found declaration: Random:Double; system.pp(339) Fatal: There were 4 errors compiling module, stopping Fatal: Compilation aborted command doing the RTL build was: make --directory=/Users/ring/devel/fpc-svn FPCDIR=/Users/ring/devel/fpc-svn FPCMAKE=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/fpcmake PPUMOVE=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppumove INSTALL_PREFIX=/Users/ring/fpcupdeluxe/fpc INSTALL_BINDIR=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin CROSSBINDIR=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin FPC=/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm rtl_clean rtl_all CROSSINSTALL=1 CPU_SOURCE=x86_64 OS_SOURCE=darwin OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv6m NOGDBMI=1 BINUTILSPREFIX=arm-embedded- OPT='-vw-n-h-l-d-u-t-p-c- -ap' CROSSOPT= INSTALL_UNITDIR=/Users/ring/fpcupdeluxe/fpc/units/arm-embedded/armv6m/rtl ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem compiling rtl for arm-embedded with -CfFPV4_SP_D16
Compiles again, thank you! I should have copied the header of the mail into the message, then things would have been more clear, sorry! Michael Am 17.07.20 um 18:46 schrieb Florian Klämpfl: Am 17.07.20 um 18:03 schrieb Michael Ring via fpc-devel: As the problem is still there I checked where it comes from, revision 45750 is to blame, 45749 compiles just fine, 45750 kills the build of rtl for armv7em It is not armv7em related but fpv4_sp_d16. I hope r45799 fixes it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem compiling rtl for arm-embedded with -CfFPV4_SP_D16
As the problem is still there I checked where it comes from,
revision 45750
is to blame, 45749 compiles just fine, 45750 kills the build of rtl for
armv7em
Michael
Am 10.07.20 um 23:46 schrieb Michael Ring via fpc-devel:
I today updated to latest trunk, I am getting an error compiling rtl
for arm-embedded, but only for armv7em with enabled FPU, armv6m and
armv7m compile fine.
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7em -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE.
-FU/Users/ring/devel/fpc/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c-
-ap -darm -dRELEASE -Sg -CfFPV4_SP_D16 -Us -Sg system.pp @system.cfg
{standard input}: Assembler messages:
{standard input}:18442: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:18517: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:18646: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:18985: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:18992: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:18999: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:19362: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:20095: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:20909: Error: selected FPU does not support
instruction -- `vneggt.f32 d0,d0'
{standard input}:21049: Error: selected FPU does not support
instruction -- `vnegne.f32 d0,d0'
{standard input}:21134: Error: selected FPU does not support
instruction -- `vneg.f32 d0,d0'
{standard input}:21619: Error: selected FPU does not support
instruction -- `vneglt.f32 d0,d0'
system.pp(339) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[2]: *** [system.ppu] Error 1
make[1]: *** [embedded_all] Error 2
make: *** [rtl_all] Error 2
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Problem compiling rtl for arm-embedded with -CfFPV4_SP_D16
I today updated to latest trunk, I am getting an error compiling rtl for
arm-embedded, but only for armv7em with enabled FPU, armv6m and armv7m
compile fine.
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7em -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm
-FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE.
-FU/Users/ring/devel/fpc/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap
-darm -dRELEASE -Sg -CfFPV4_SP_D16 -Us -Sg system.pp @system.cfg
{standard input}: Assembler messages:
{standard input}:18442: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:18517: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:18646: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:18985: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:18992: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:18999: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:19362: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:20095: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:20909: Error: selected FPU does not support instruction
-- `vneggt.f32 d0,d0'
{standard input}:21049: Error: selected FPU does not support instruction
-- `vnegne.f32 d0,d0'
{standard input}:21134: Error: selected FPU does not support instruction
-- `vneg.f32 d0,d0'
{standard input}:21619: Error: selected FPU does not support instruction
-- `vneglt.f32 d0,d0'
system.pp(339) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[2]: *** [system.ppu] Error 1
make[1]: *** [embedded_all] Error 2
make: *** [rtl_all] Error 2
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Linking not working anymore on latest trunk for target arm-freertos (plus fix)
Hi, Linking on arm-freertos target did not work after the merge of some
of Christo's fixes for esp32-freertos.
Here's the fix for the issue (also attached as diff), Florian, can you
please check & apply this patch?
Thank you,
Michael
diff --git a/compiler/systems/t_freertos.pas
b/compiler/systems/t_freertos.pas
index e8f5f8507d..742c71d4c5 100644
--- a/compiler/systems/t_freertos.pas
+++ b/compiler/systems/t_freertos.pas
@@ -82,9 +82,9 @@ begin
'-L $IDF_PATH/components/esp_rom/esp32/ld '+
'-T esp32.rom.ld -T esp32.rom.libgcc.ld -T
esp32.rom.newlib-data.ld -T esp32.rom.syscalls.ld -T
esp32.rom.newlib-funcs.ld '+
'-L . -T esp32_out.ld -T esp32.project.ld '+
- '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld'
- else
- ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC
$GCSECTIONS $STRIP $MAP -L. -o $EXE -T $RES';
+ '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld';
+{$else}
+ ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC
$GCSECTIONS $STRIP $MAP -L. -o $EXE -T $RES';
{$endif xtensa}
end;
end;
@@ -1160,7 +1160,8 @@ begin
success:=DoExec(binstr,cmdstr,true,false);
end;
-
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
+ if IDF_PATH <> '' then
+
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
FixedExeFileName:=maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.elf')));
GCSectionsStr:='--gc-sections';
diff --git a/compiler/systems/t_freertos.pas b/compiler/systems/t_freertos.pas
index e8f5f8507d..742c71d4c5 100644
--- a/compiler/systems/t_freertos.pas
+++ b/compiler/systems/t_freertos.pas
@@ -82,9 +82,9 @@ begin
'-L $IDF_PATH/components/esp_rom/esp32/ld '+
'-T esp32.rom.ld -T esp32.rom.libgcc.ld -T esp32.rom.newlib-data.ld
-T esp32.rom.syscalls.ld -T esp32.rom.newlib-funcs.ld '+
'-L . -T esp32_out.ld -T esp32.project.ld '+
- '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld'
- else
- ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC $GCSECTIONS
$STRIP $MAP -L. -o $EXE -T $RES';
+ '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld';
+{$else}
+ ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC $GCSECTIONS
$STRIP $MAP -L. -o $EXE -T $RES';
{$endif xtensa}
end;
end;
@@ -1160,7 +1160,8 @@ begin
success:=DoExec(binstr,cmdstr,true,false);
end;
-
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
+ if IDF_PATH <> '' then
+
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
FixedExeFileName:=maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.elf')));
GCSectionsStr:='--gc-sections';
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Linking not working anymore on latest trunk for target arm-freertos (plus fix)
Hi, Linking on arm-freertos target did not work after the merge of some
of Christo's fixes for esp32-freertos.
Here's the fix for the issue (also attached as diff), Florian, can you
please check & apply this patch?
Thank you,
Michael
diff --git a/compiler/systems/t_freertos.pas
b/compiler/systems/t_freertos.pas
index e8f5f8507d..742c71d4c5 100644
--- a/compiler/systems/t_freertos.pas
+++ b/compiler/systems/t_freertos.pas
@@ -82,9 +82,9 @@ begin
'-L $IDF_PATH/components/esp_rom/esp32/ld '+
'-T esp32.rom.ld -T esp32.rom.libgcc.ld -T
esp32.rom.newlib-data.ld -T esp32.rom.syscalls.ld -T
esp32.rom.newlib-funcs.ld '+
'-L . -T esp32_out.ld -T esp32.project.ld '+
- '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld'
- else
- ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC
$GCSECTIONS $STRIP $MAP -L. -o $EXE -T $RES';
+ '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld';
+{$else}
+ ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC
$GCSECTIONS $STRIP $MAP -L. -o $EXE -T $RES';
{$endif xtensa}
end;
end;
@@ -1160,7 +1160,8 @@ begin
success:=DoExec(binstr,cmdstr,true,false);
end;
-
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
+ if IDF_PATH <> '' then
+
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
FixedExeFileName:=maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.elf')));
GCSectionsStr:='--gc-sections';
diff --git a/compiler/systems/t_freertos.pas b/compiler/systems/t_freertos.pas
index e8f5f8507d..742c71d4c5 100644
--- a/compiler/systems/t_freertos.pas
+++ b/compiler/systems/t_freertos.pas
@@ -82,9 +82,9 @@ begin
'-L $IDF_PATH/components/esp_rom/esp32/ld '+
'-T esp32.rom.ld -T esp32.rom.libgcc.ld -T esp32.rom.newlib-data.ld
-T esp32.rom.syscalls.ld -T esp32.rom.newlib-funcs.ld '+
'-L . -T esp32_out.ld -T esp32.project.ld '+
- '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld'
- else
- ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC $GCSECTIONS
$STRIP $MAP -L. -o $EXE -T $RES';
+ '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld';
+{$else}
+ ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC $GCSECTIONS
$STRIP $MAP -L. -o $EXE -T $RES';
{$endif xtensa}
end;
end;
@@ -1160,7 +1160,8 @@ begin
success:=DoExec(binstr,cmdstr,true,false);
end;
-
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
+ if IDF_PATH <> '' then
+
Replace(Info.ExeCmd[1],'$'+IDF_PATH,maybequoted(GetEnvironmentVariable(IDF_PATH)));
FixedExeFileName:=maybequoted(ScriptFixFileName(ChangeFileExt(current_module.exefilename,'.elf')));
GCSectionsStr:='--gc-sections';
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Is there a less clumsy way to define a weak procedure?
I have to define a weak procedure in implementation of a unit to make the linker happy in a special case: procedure vPortFree; external name 'vPortFree'; procedure vPortFreeStub; assembler; nostackframe; asm .long vPortFree .weak vPortFree .set vPortFree,vPortFreeStub bkpt end; is there a more elegant way to do this? My target is arm-freertos. The function is actually never called, this is why it consists of a bkpt. Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Cannot compile fpc with latest trunk on MacOSX
make -j clean buildbase FPC=~/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh works fine with fpc checkout from a few days ago, with todays trunk I get the following error: /Library/Developer/CommandLineTools/usr/bin/make rtl /Library/Developer/CommandLineTools/usr/bin/make -C /Users/ring/devel/fpc/rtl 'OPT= ' all /Library/Developer/CommandLineTools/usr/bin/make -C darwin all /Users/ring/devel/fpc/compiler/ppc1 -Ur -dFPC_USE_LIBC -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fi../bsd -Fi../bsd/x86_64 -Fi../darwin/x86_64 -FE. -FU/Users/ring/devel/fpc/rtl/units/x86_64-darwin -dx86_64 -dRELEASE -Us -Sg ../bsd/system.pp /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:3469:15: error: invalid operand for instruction movzbl %r12b,%rdx ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:8698:16: error: invalid operand for instruction movzbl (%r14),%r13 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24549:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24557:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24801:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24807:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ system.pp(398) Error: Error while assembling exitcode 1 system.pp(398) Fatal: There were 2 errors compiling module, stopping ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible error in generated code for arm?
Arg... I feel completely stupid! Thank you for the Hint Jonas, using pxBuffer^ did the trick! Michael Am 22.04.20 um 11:15 schrieb Jonas Maebe: On 22/04/2020 00:09, Michael Ring via fpc-devel wrote: function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer; cdecl; begin FillChar(pxBuffer,count,value); Result := pxBuffer; end; You need pxBuffer^ instead of pxBuffer (you want to fill the block to which pxBuffer points, not the 4 bytes of pxBuffer itself). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible error in generated code for arm?
The information you see is coming straight out of the debugger (Segger
Ozone),
and perhaps I should have said this in the first post,
the pointer that is fed in the Fillchar procedure is complete nonsense,
it points into the stack area which means im my case that fillchar
overwrites the stack and at some point writes into non-RAM which crashes
the cpu.
Value of R0 inside of Fillchar: 20017ef4 (Stack Area at the end of RAM)
Value of R0 on entry: 20f8 which looks OK as it is close to the
start of RAM where it got statically allocated:
implementation
var
xIdleTaskTCB : TStaticTask;
uxIdleTaskStack : array[0..configMINIMAL_STACK_SIZE-1] of TStackType;
xTimerTaskTCB : TStaticTask;
uxTimerTaskStack : array[0..configTIMER_TASK_STACK_DEPTH-1] of
TStackType;
The only other thing than a compiler bug could be that my Implementation
of the memset wrapper is wrong, the prototype is:
void * memset ( void * ptr, int value, size_t num );
and both h2pas and me came to the same implementation:
function memset(pxBuffer:pointer; value : uint32; count : Tsize):pointer; cdecl;
You can ignore the fact that I get an uint32 passed in and Fillchar uses
a byte, only the byte part is relevant:
From C Documentation of memset:
void * memset ( void * ptr, int value, size_t num );
Fill block of memory
Sets the first /num/ bytes of the block of memory pointed by
/ptr/ to the specified /value/ (interpreted as an unsigned char).
I have also hacked the code of my memset function in a way that I think
that it should work:
begin
asm
LDR R0, [R11, #-0x30]
LDRB R2, [R11, #-0x34]
LDR R1, [R11, #-0x38]
bl fillchar
end;
Result := pxBuffer;
end;
Implemented this way the function works as expected.
Michael
Am 22.04.20 um 01:10 schrieb Alexander Grotewohl:
Can you run gdb on there? When you break inside memset does the
pxBuffer pointer make sense (not 0x0)? Do the other two variables come
in correctly?
Do you call memset or does an api in the OS call it? Perhaps it's a
pointer to a pointer on accident?
If you are required to provide memset are you also providing other
memory functions, for example to allocate? Is it passing a valid
pointer back (one that eventually gets to memset)?
Just a bit of a brainstorm.. sorry if I've oversimplified or missed
the mark entirely :)
--
Alexander Grotewohl
https://dcclost.com
*From:* fpc-devel on behalf
of Michael Ring via fpc-devel
*Sent:* Tuesday, April 21, 2020 6:09:57 PM
*To:* fpc-devel@lists.freepascal.org
*Cc:* Michael Ring
*Subject:* [fpc-devel] Possible error in generated code for arm?
I have the following code in a unit (I need to provide a memset
function to be able to link to freertos):
function memset(pxBuffer:pointer; value : byte; count :
Tsize):pointer; cdecl;
begin
FillChar(pxBuffer,count,value);
Result := pxBuffer;
end;
When I look at the assembler code generated by latest Trunk fpc
something is very odd @08000970, I'd expect to see
LDR R0, [R11, #-0x30]
but in fact I see:
08000970 SUB.W R0, R11, #0x30
which makes no sense to me and later the code crashes inside of the
FillChar routine.
Compiler Bug? Or me overlooking something? I tried to compile with -O-
and -O1, with -O2 the generated code is a little different but there
the SP is loaded to R0 which I do not understand, I'd expect R0 to be
set to address of pxBuffer. (this is for armv7em, for armv6 also looks
odd.
Thank you for your help,
Michael
FREERTOS_$$_MEMSET$POINTER$BYTE$LONGWORD$$POINTER
DEBUGSTART_$FREERTOS
memset
$Thumb
begin
08000958 MOV R12, SP
0800095A PUSH.W {R11, LR}
0800095E SUB.W R11, R12, #4
08000962 SUB SP, SP, #0x48
08000964 STR R0, [R11, #-0x30]
08000968 STRB R1, [R11, #-0x34]
0800096C STR R2, [R11, #-0x38]
FillChar(pxBuffer,count,value);
08000970 SUB.W R0, R11, #0x30
08000974 LDRB R2, [R11, #-0x34]
08000978 LDR R1, [R11, #-0x38]
0800097C BL SYSTEM_$$_FILLCHAR$formal$LONGINT$BYTE ; 0x080002
Result := pxBuffer;
08000980 LDR R0, [R11, #-0x30]
08000984 STR R0, [R11, #-0x3C]
Am 21.04.20 um 23:07 schrieb Joao Schuler:
just as point for consideration, I'm not sure if data alignment will
improve speed on future processors:
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
Food for thought: imagine if we had single (32 bits floating point)
values dynamic arrays with 1 million values each: a b and c. I would
love to have something like this:
a := b + c;
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
<mailto:fpc-devel@lists.freepascal.org>
https://lists.freepascal.org/cgi
[fpc-devel] Possible error in generated code for arm?
I have the following code in a unit (I need to provide a memset function
to be able to link to freertos):
function memset(pxBuffer:pointer; value : byte; count : Tsize):pointer;
cdecl;
begin
FillChar(pxBuffer,count,value);
Result := pxBuffer;
end;
When I look at the assembler code generated by latest Trunk fpc
something is very odd @08000970, I'd expect to see
LDR R0, [R11, #-0x30]
but in fact I see:
08000970 SUB.W R0, R11, #0x30
which makes no sense to me and later the code crashes inside of the
FillChar routine.
Compiler Bug? Or me overlooking something? I tried to compile with -O-
and -O1, with -O2 the generated code is a little different but there the
SP is loaded to R0 which I do not understand, I'd expect R0 to be set to
address of pxBuffer. (this is for armv7em, for armv6 also looks odd.
Thank you for your help,
Michael
FREERTOS_$$_MEMSET$POINTER$BYTE$LONGWORD$$POINTER
DEBUGSTART_$FREERTOS
memset
$Thumb
begin
08000958 MOV R12, SP
0800095A PUSH.W {R11, LR}
0800095E SUB.W R11, R12, #4
08000962 SUB SP, SP, #0x48
08000964 STR R0, [R11, #-0x30]
08000968 STRB R1, [R11, #-0x34]
0800096C STR R2, [R11, #-0x38]
FillChar(pxBuffer,count,value);
08000970 SUB.W R0, R11, #0x30
08000974 LDRB R2, [R11, #-0x34]
08000978 LDR R1, [R11, #-0x38]
0800097C BL SYSTEM_$$_FILLCHAR$formal$LONGINT$BYTE ;
0x080002
Result := pxBuffer;
08000980 LDR R0, [R11, #-0x30]
08000984 STR R0, [R11, #-0x3C]
Am 21.04.20 um 23:07 schrieb Joao Schuler:
just as point for consideration, I'm not sure if data alignment will
improve speed on future processors:
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
Food for thought: imagine if we had single (32 bits floating point)
values dynamic arrays with 1 million values each: a b and c. I would
love to have something like this:
a := b + c;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
Trunk now builds without issues for armv6m, armv7m and armv7em, here's the patch to add the license and the renames to make the interrupts cmsis compatible. http://temp.michael-ring.org/cmsis_plus_license.patch Michael Am 20.04.20 um 23:11 schrieb Michael Ring via fpc-devel: Am 20.04.20 um 22:14 schrieb Florian Klämpfl: Am 20.04.20 um 00:03 schrieb Michael Ring via fpc-devel: Thanks! Your commit is close, but not yet there... to make it work it was necessary for me to re-create the Makefiles, arm-freertos was missing in the root makefile and some others, did you rebuild fpcmake before using it? Pierre recreated the makefiles already, so it should be fine, right? Yes, I could start the build from trunk You also did not include the rtl/freertos/arm directory (I guess on purpose, it is currently an evil clone of rtl/embedded/arm): Ok. I added them. without that directory and it's content the build breaks. I checked if you did some magic to re-use the rtl/embedded/arm directory but this does not seem to be the case. No, I applied the patch and forgot to add them. No worries Currently it is also perhaps a good idea to have a new directory for freertos compatible units, from what I know today I will have to change the interrupt-names defined in the unitfiles to be CMSIS (and for that FreeRTOS) compatible. This means that we will likely have to rename interrupt names like: PendSV_Interrupt to PendSV_Handler so that FreeRTOS can properly provide it's own routines for handling SysTick, PendSV and SVCall Interrupt Handlers. Yes. Another thing: some of the files miss a header, so the correct license. If some of them are made by you, can you please provide a header? Sorry, I will provide new versions with proper headers ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
Am 20.04.20 um 22:14 schrieb Florian Klämpfl: Am 20.04.20 um 00:03 schrieb Michael Ring via fpc-devel: Thanks! Your commit is close, but not yet there... to make it work it was necessary for me to re-create the Makefiles, arm-freertos was missing in the root makefile and some others, did you rebuild fpcmake before using it? Pierre recreated the makefiles already, so it should be fine, right? Yes, I could start the build from trunk You also did not include the rtl/freertos/arm directory (I guess on purpose, it is currently an evil clone of rtl/embedded/arm): Ok. I added them. without that directory and it's content the build breaks. I checked if you did some magic to re-use the rtl/embedded/arm directory but this does not seem to be the case. No, I applied the patch and forgot to add them. No worries Currently it is also perhaps a good idea to have a new directory for freertos compatible units, from what I know today I will have to change the interrupt-names defined in the unitfiles to be CMSIS (and for that FreeRTOS) compatible. This means that we will likely have to rename interrupt names like: PendSV_Interrupt to PendSV_Handler so that FreeRTOS can properly provide it's own routines for handling SysTick, PendSV and SVCall Interrupt Handlers. Yes. Another thing: some of the files miss a header, so the correct license. If some of them are made by you, can you please provide a header? Sorry, I will provide new versions with proper headers ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
Thanks! Your commit is close, but not yet there... to make it work it was necessary for me to re-create the Makefiles, arm-freertos was missing in the root makefile and some others, did you rebuild fpcmake before using it? You also did not include the rtl/freertos/arm directory (I guess on purpose, it is currently an evil clone of rtl/embedded/arm): without that directory and it's content the build breaks. I checked if you did some magic to re-use the rtl/embedded/arm directory but this does not seem to be the case. Currently it is also perhaps a good idea to have a new directory for freertos compatible units, from what I know today I will have to change the interrupt-names defined in the unitfiles to be CMSIS (and for that FreeRTOS) compatible. This means that we will likely have to rename interrupt names like: PendSV_Interrupt to PendSV_Handler so that FreeRTOS can properly provide it's own routines for handling SysTick, PendSV and SVCall Interrupt Handlers. There may be other solutions to this problem, read somewhere that one can replace symbols in the linker step, but for the first version it would be good to have the changed units in trunk. Here's a zip with the missing files: http://temp.michael-ring.org/freertos-arm-missing.zip Michael Am 19.04.20 um 23:00 schrieb Florian Klämpfl: Am 19.04.20 um 17:25 schrieb Michael Ring via fpc-devel: I have uploaded my patch to: http://temp.michael-ring.org/fpc-arm-freertos.patch I have committed it with a few changes, let's see how it works :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
I have uploaded my patch to: http://temp.michael-ring.org/fpc-arm-freertos.patch I have left out the generated Makefiles to keep the patch (kind of) readable. I am able to build the target like this: make -j clean buildbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv7em CROSSOPT="-CfFPV4_SP_D16 -XParm-embedded-" or make -j clean buildbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv6m CROSSOPT="-CfSOFT -XParm-embedded-" make -j clean buildbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv7m CROSSOPT="-CfSOFT -XParm-embedded-" Fun Fact: I have to include -CfSOFT in CROSSOPT for armv6m/7m or I will get this error: /Library/Developer/CommandLineTools/usr/bin/make -C rtl all /Library/Developer/CommandLineTools/usr/bin/make -C freertos all /bin/mkdir -p /Users/ring/devel/fpc-freertos/rtl/units/arm-freertos /Users/ring/devel/fpc-freertos/compiler/ppcrossarm -Cparmv6m -Ur -Tfreertos -Parm -XParm-freertos- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE. -FU/Users/ring/devel/fpc-freertos/rtl/units/arm-freertos -darm -dRELEASE -XParm-embedded- -Us -Sg system.pp @system.cfg system.inc(416,5) Fatal: Internal error 200312126 Do you have an idea why? I compared to the embedded target but could not find something obvious The freertos bindings are not included yet as I am still testing & learning and I need your guidance on how to provide the lib/*.o files for freertos: I currently build freertos rtl as three different versions with a hopefully sane base-set of configuration options, the question is where to put the matching *.o or *.a files, check them in in fpc or provide build instructions on the Wiki similar to the buildinstructions for xtensa target?? I have uploaded a zipfile with everything needed to build a freertos environment: http://temp.michael-ring.org/FreeRTOS-Bootstrap.zip The Build also includes prebuilt .o files. To build yourself you will first have to manually adjust the buildFreeRTOS.sh script so that it points to a correct arm-none-eabi-gcc. Michael Am 19.04.20 um 15:30 schrieb Florian Klämpfl: Am 06.04.20 um 20:54 schrieb Michael Ring via fpc-devel: I was able to compile my first hello world for esp32, however I had to patch a few files so that compiling works for 4.0 / 4.1 Branch of esp-idf Florian, can you please have a look at the patches and apply them if they are OK? I have committed the patch with some extensions/adaptions. With current trunk, I can build a hello world following the wiki instructions with ESP-IDF 4.0. Regarding the FreeRTOS binding for ARM: can you provide a patch somewhere? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ 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
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 + Am 19.04.20 um 13:23 schrieb Florian Klämpfl: Am 01.04.20 um 18:58 schrieb Christo Crause via fpc-devel: 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] latest trunk does not compile for armv6m embedded
Working again, thank you! Am 19.04.20 um 13:05 schrieb Florian Klämpfl: Am 19.04.20 um 10:45 schrieb Michael Ring via fpc-devel: Building for armv6m does not work, building for armv7m/em is fine: Thanks for noticing. Fixed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] latest trunk does not compile for armv6m embedded
Building for armv6m does not work, building for armv7m/em is fine: make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv6m /Library/Developer/CommandLineTools/usr/bin/make rtl_all FPC=/Users/ring/devel/fpc/compiler/ppcrossarm FPCFPMAKE=/Users/ring/devel/fpc/compiler/ppc RELEASE=1 'OPT=' 'FPCMAKEOPT=' /Library/Developer/CommandLineTools/usr/bin/make -C rtl all /Library/Developer/CommandLineTools/usr/bin/make -C embedded all /bin/mkdir -p /Users/ring/devel/fpc/rtl/units/arm-embedded /Users/ring/devel/fpc/compiler/ppcrossarm -Cparmv6m -Ur -Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE. -FU/Users/ring/devel/fpc/rtl/units/arm-embedded -darm -dRELEASE -Us -Sg system.pp @system.cfg /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s: Assembler messages: /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:57817: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:58293: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:65493: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:72437: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:72797: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:72926: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:73068: Error: lo register required -- `ldr r15,[r0,r1]' /Users/ring/devel/fpc/rtl/units/arm-embedded/system.s:73214: Error: lo register required -- `ldr r15,[r0,r1]' system.pp(339) Error: Error while assembling exitcode 1 system.pp(339) Fatal: There were 2 errors compiling module, stopping ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?
Compile compiler&rtl works again!
Michael
Am 12.04.20 um 17:35 schrieb Michael Ring via fpc-devel:
Thanks, but unfortunately this created some issues, both when I build
plain armv6m/armv7em embedded compiler+rtl and my freertos target
(Errors are the same)
armv6m embedded from trunk compiling without -Cf flag:
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv6m -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE.
-FU/Users/ring/devel/fpc/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c-
-ap -darm -dRELEASE ../inc/iso7185.pp
iso7185.pp(267,13) Fatal: Internal error 2009112404
armv7em compiling with -CfFPV4_SP_D16
/Library/Developer/CommandLineTools/usr/bin/make -C embedded all
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7em -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE.
-FU/Users/ring/devel/fpc/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c-
-ap -CfFPV4_SP_D16 -darm -dRELEASE -Us -Sg system.pp @system.cfg
{standard input}: Assembler messages:
{standard input}:19643: Error: selected FPU does not support
instruction -- `vmov d0,r0,r1'
{standard input}:19659: Error: selected FPU does not support
instruction -- `vmov d0,r0,r1'
Compiling the compiler+rtl worked fine before applying the following
changes:
Updating 6d7560f142..94d20ceb05
Fast-forward
compiler/arm/aasmcpu.pas | 1 +
compiler/arm/cgcpu.pas | 43
+++
compiler/arm/cpuinfo.pas | 40 ++--
compiler/arm/narmadd.pas | 6 +++---
compiler/arm/narmcnv.pas | 6 +++---
compiler/arm/narminl.pas | 12 ++--
compiler/arm/narmmat.pas | 4 ++--
compiler/arm/narmutil.pas | 1 +
compiler/globals.pas | 1 +
9 files changed, 66 insertions(+), 48 deletions(-)
In case you need the freertos target, it is here, work in progress, I
am now creating freertos bindings:
http://temp.michael-ring.org/targetarmfreertos.patch
Am 12.04.20 um 16:26 schrieb Florian Klämpfl:
Am 12.04.20 um 14:13 schrieb Michael Ring via fpc-devel:
Thank you very much for your effort!
I added FPV4_SP_D16.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?
Thanks, but unfortunately this created some issues, both when I build
plain armv6m/armv7em embedded compiler+rtl and my freertos target
(Errors are the same)
armv6m embedded from trunk compiling without -Cf flag:
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv6m -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm
-FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE.
-FU/Users/ring/devel/fpc/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap
-darm -dRELEASE ../inc/iso7185.pp
iso7185.pp(267,13) Fatal: Internal error 2009112404
armv7em compiling with -CfFPV4_SP_D16
/Library/Developer/CommandLineTools/usr/bin/make -C embedded all
/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin/ppcarm -Cparmv7em -Ur
-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm
-FD/Users/ring/fpcupdeluxe/fpc/bin/x86_64-darwin -FE.
-FU/Users/ring/devel/fpc/rtl/units/arm-embedded -vw-n-h-l-d-u-t-p-c- -ap
-CfFPV4_SP_D16 -darm -dRELEASE -Us -Sg system.pp @system.cfg
{standard input}: Assembler messages:
{standard input}:19643: Error: selected FPU does not support instruction
-- `vmov d0,r0,r1'
{standard input}:19659: Error: selected FPU does not support instruction
-- `vmov d0,r0,r1'
Compiling the compiler+rtl worked fine before applying the following
changes:
Updating 6d7560f142..94d20ceb05
Fast-forward
compiler/arm/aasmcpu.pas | 1 +
compiler/arm/cgcpu.pas | 43 +++
compiler/arm/cpuinfo.pas | 40 ++--
compiler/arm/narmadd.pas | 6 +++---
compiler/arm/narmcnv.pas | 6 +++---
compiler/arm/narminl.pas | 12 ++--
compiler/arm/narmmat.pas | 4 ++--
compiler/arm/narmutil.pas | 1 +
compiler/globals.pas | 1 +
9 files changed, 66 insertions(+), 48 deletions(-)
In case you need the freertos target, it is here, work in progress, I am
now creating freertos bindings:
http://temp.michael-ring.org/targetarmfreertos.patch
Am 12.04.20 um 16:26 schrieb Florian Klämpfl:
Am 12.04.20 um 14:13 schrieb Michael Ring via fpc-devel:
Thank you very much for your effort!
I added FPV4_SP_D16.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?
Thank you very much for your effort! Michael Am 12.04.20 um 11:34 schrieb Florian Klämpfl: Am 12.04.20 um 10:49 schrieb je...@j-software.dk: I'm pretty sure that's what fpv4_s16 is. That was implemented for cortex m4. Don't have the spec here currently though Yes. It looks like this. Nevertheless, for consistent naming I'll add fpv4-sp-d16 with the same fpu capabilities as fpv4_s16 (which appears to be broken currently). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?
I found this reference manual for floating point instructions: https://www.st.com/resource/en/programming_manual/dm00046982-stm32-cortexm4-mcus-and-mpus-programming-manual-stmicroelectronics.pdf and this high level overview: https://embeddedartistry.com/blog/2017/10/11/demystifying-arm-floating-point-compiler-options/ What is funny is that I did not find FPV4_S16 in the link above, only *VFPv4-D32,**VFPv4-D16 and ***VFPv4U** Here: https://sourceware.org/binutils/docs/as/ARM-Options.html#ARM-Options I only find |vfpv4|, |vfpv4-d16|, |fpv4-sp-d16| so no idea what FPV4_S16 actually is.. Michael Am 11.04.20 um 21:42 schrieb Florian Klaempfl: Am 11.04.2020 um 21:03 schrieb Michael Ring via fpc-devel: I have now set up new target freertos-arm and want to start playing arround with freertos. I have compiled freertos with STM32CubeIDE, only 'problem' is that I need to compile with floting point enabled, with Soft-Float the build fails. For STM32F401RE Chip the C-compiler selects -mfpu=fpv4-sp-d16 -mfloat-abi=hard but Freepascal doex not seem to support exactly this abi, I see: NONE SOFT LIBGCC FPA FPA10 FPA11 VFPV2 VFPV3 NEON_VFPV3 VFPV3_D16 FPV4_S16 VFPV4 NEON_VFPV4 Which setting should I use? VFPV3_D16 or something else? Let's just add it. What properties does it have? Do you have know some reference by heard? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?
I have now set up new target freertos-arm and want to start playing arround with freertos. I have compiled freertos with STM32CubeIDE, only 'problem' is that I need to compile with floting point enabled, with Soft-Float the build fails. For STM32F401RE Chip the C-compiler selects -mfpu=fpv4-sp-d16 -mfloat-abi=hard but Freepascal doex not seem to support exactly this abi, I see: NONE SOFT LIBGCC FPA FPA10 FPA11 VFPV2 VFPV3 NEON_VFPV3 VFPV3_D16 FPV4_S16 VFPV4 NEON_VFPV4 Which setting should I use? VFPV3_D16 or something else? Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
I removed Modules/Libs that I could not find in v4.0/v4.1 Release of idf. As official stable release of idf is currently 4.0 I think it makes sense to make sure that this release builds out of the box. As esp32 is bleeding edge both for compiler and freertos I have done most patches that are necessary to make freertos compile with arm target. There at least the compiler is pretty stable and overall the whole environment is a lot less complex, so perhaps making freertos work is a little easier. Is anybody already working on freertos bindings? Michael By the way, I added a few missing points to the wiki Am 06.04.20 um 21:15 schrieb Florian Klämpfl: Am 06.04.20 um 20:54 schrieb Michael Ring via fpc-devel: I was able to compile my first hello world for esp32, however I had to patch a few files so that compiling works for 4.0 / 4.1 Branch of esp-idf Florian, can you please have a look at the patches and apply them if they are OK? To be honest, I have not the slightest clue if they are ok or not :) To be honest I simply did a lot of trial and error for the current port. Do you have any explanations for the needed changes? BTW: I started a wiki page on it: https://wiki.freepascal.org/ESP32 (not end user ready, just for people interested on improving the port :)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
I was able to compile my first hello world for esp32, however I had to
patch a few files so that compiling works for 4.0 / 4.1 Branch of esp-idf
Florian, can you please have a look at the patches and apply them if
they are OK?
diff --git a/compiler/systems/t_freertos.pas
b/compiler/systems/t_freertos.pas
index 3698f28dc1..a0788751ec 100644
--- a/compiler/systems/t_freertos.pas
+++ b/compiler/systems/t_freertos.pas
@@ -77,7 +77,7 @@ begin
if target_info.system=system_xtensa_freertos then
ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC
$GCSECTIONS $STRIP $MAP -L. -o $EXE -T $RES '+
'-u call_user_start_cpu0 -u ld_include_panic_highint_hdl -u
esp_app_desc -u vfs_include_syscalls_impl -u
pthread_include_pthread_impl -u pthread_include_pthread_cond_impl -u
pthread_include_pthread_local_storage_impl -u newlib_include_locks_impl
-u newlib_include_heap_impl -u newlib_include_syscalls_impl -u
newlib_include_pthread_impl -u app_main -u uxTopUsedPriority '+
- '-L $IDF_PATH/components/esp_rom/esp32/ld -T
esp32.rom.newlib-funcs-time.ld '+
+ '-L $IDF_PATH/components/esp_rom/esp32/ld '+
'-T esp32.rom.ld -T esp32.rom.libgcc.ld -T
esp32.rom.newlib-data.ld -T esp32.rom.syscalls.ld -T
esp32.rom.newlib-funcs.ld '+
'-L . -T esp32_out.ld -T esp32.project.ld '+
'-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld'
@@ -1523,10 +1523,10 @@ begin
{ generate linker maps for esp32 }
binstr:='$IDF_PATH/tools/ldgen/ldgen.py';
cmdstr:='--config sdkconfig --fragments
$IDF_PATH/components/xtensa/linker.lf $IDF_PATH/components/soc/linker.lf
$IDF_PATH/components/esp_event/linker.lf '+
- '$IDF_PATH/components/spi_flash/linker.lf
$IDF_PATH/components/esp_wifi/linker.lf
$IDF_PATH/components/lwip/linker.lf $IDF_PATH/components/log/linker.lf '+
+ '$IDF_PATH/components/spi_flash/linker.lf
$IDF_PATH/components/esp_wifi/linker.lf
$IDF_PATH/components/lwip/linker.lf '+
'$IDF_PATH/components/heap/linker.lf
$IDF_PATH/components/esp_ringbuf/linker.lf
$IDF_PATH/components/espcoredump/linker.lf
$IDF_PATH/components/esp32/linker.lf '+
'$IDF_PATH/components/esp32/ld/esp32_fragments.lf
$IDF_PATH/components/freertos/linker.lf
$IDF_PATH/components/newlib/newlib.lf '+
- '$IDF_PATH/components/app_trace/linker.lf
$IDF_PATH/components/esp_gdbstub/linker.lf '+
+ '$IDF_PATH/components/esp_gdbstub/linker.lf '+
'--input $IDF_PATH/components/esp32/ld/esp32.project.ld.in
--output ./esp32.project.ld --kconfig $IDF_PATH/Kconfig --env-file
config.env '+
'--libraries-file ldgen_libraries --objdump
xtensa-esp32-elf-objdump';
Replace(binstr,'$IDF_PATH',maybequoted(GetEnvironmentVariable('IDF_PATH')));
diff --git a/rtl/freertos/xtensa/esp32.pp b/rtl/freertos/xtensa/esp32.pp
index 1bc9d3bcf9..e7070e082b 100644
--- a/rtl/freertos/xtensa/esp32.pp
+++ b/rtl/freertos/xtensa/esp32.pp
@@ -22,10 +22,10 @@ unit esp32;
{$linklib spi_flash,static}
{$linklib app_update,static}
{$linklib xtensa,static}
-{$linklib esp_timer,static}
+//{$linklib esp_timer,static}
{$linklib bootloader_support,static}
{$linklib pthread,static}
-{$linklib soc_esp32,static}
+//{$linklib soc_esp32,static}
{$linklib hal,static}
{$linklib c,static}
{$linklib esp_event,static}
Am 05.04.20 um 14:50 schrieb Michael Ring via fpc-devel:
Just to be sure, from your Path settings it looks like you are using
esp-idf from the release/v4.0 Branch, correct?
Michael
Am 04.04.20 um 19:44 schrieb Florian Klämpfl:
Am 04.04.20 um 16:06 schrieb Christo Crause via fpc-devel:
I'm keen to test the xtensa-freertos target, but it seems there are
a couple of patches missing from trunk.
It is possible to build an xtensa cross compiler, but the make files
doesn't know the xtensa-freertos target. To get the make files in
rtl updated, one needs to rebuild fpcmake, edit rtl/MakeFile.fpc
and add "dirs_freertos=freertos" to the target list, then run
fpcmake. At this point the the following make command proceeds up to
sysutils:
make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CPU_TARGET=xtensa
OS_TARGET=freertos BINUTILSPREFIX=xtensa-esp32-elf-
where the following errors crop up:
syssbh.inc(43,41) Error: Identifier not found "Double"
syssbh.inc(49,41) Error: Identifier not found "Single" etc.
I trust someone (Florian...) has a working build?
I sent Michael recently some instructions but I am not sure if they
are still working. As Pierre got qemu-xtensa working I am pushing the
linux port so we can test more easily the compiler.
- install esp-idf and execute
source ~/eps/esp-idf/export.sh
to get the pathes and environment set (namely tools path and
$IDF_PATH are needed)
Re: [fpc-devel] Problems building xtensa-freertos RTL in trunk
Just to be sure, from your Path settings it looks like you are using esp-idf from the release/v4.0 Branch, correct? Michael Am 04.04.20 um 19:44 schrieb Florian Klämpfl: Am 04.04.20 um 16:06 schrieb Christo Crause via fpc-devel: I'm keen to test the xtensa-freertos target, but it seems there are a couple of patches missing from trunk. It is possible to build an xtensa cross compiler, but the make files doesn't know the xtensa-freertos target. To get the make files in rtl updated, one needs to rebuild fpcmake, edit rtl/MakeFile.fpc and add "dirs_freertos=freertos" to the target list, then run fpcmake. At this point the the following make command proceeds up to sysutils: make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CPU_TARGET=xtensa OS_TARGET=freertos BINUTILSPREFIX=xtensa-esp32-elf- where the following errors crop up: syssbh.inc(43,41) Error: Identifier not found "Double" syssbh.inc(49,41) Error: Identifier not found "Single" etc. I trust someone (Florian...) has a working build? I sent Michael recently some instructions but I am not sure if they are still working. As Pierre got qemu-xtensa working I am pushing the linux port so we can test more easily the compiler. - install esp-idf and execute source ~/eps/esp-idf/export.sh to get the pathes and environment set (namely tools path and $IDF_PATH are needed) - use the lazarus project fpc/compiler/ppcxtens.lpt to build an xtensa compiler - build the rtl (breaks currently at sysutils, doesn't matter): cd rtl/freertos make FPC=../../compiler/xtensa/pp OS_TARGET=freertos "OPT=-Cplx6 -Cawindowed -XPxtensa-esp32-elf-" clean all - build the example hello world program from the esp-idf, copy all generated .a into e.g. ~/xtensa-esp32-elf-libs - create somewhere a hello world program, compile it with fpc/compiler/xtensa/pp -Fu../rtl/units/xtensa-freertos/ -Tfreertos -Cawindowed -XPxtensa-esp32-elf- -al -O3 -Wpesp32 -Fl~/xtensa-esp32-elf-libs -Fl$HOME/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/xtensa-esp32-elf/lib/ hello - get partition-table.bin and bootloader.bin from the hello_world example compiled above and copy them into the same dir as the compiled hello.bin - flash with esptool.py -p /dev/ttyUSB0 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 bootloader.bin 0x8000 partition-table.bin 0x1 hello.bin - monitor the output with: idf_monitor.py --port /dev/ttyUSB0 hello.elf ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] XTensa support question
How deep will freertos integration be tied to Espressif SDK? The arm target would also benefit a lot to have a proper interface to freertos Michael Am 23.03.20 um 18:36 schrieb Florian Klämpfl: Am 23.03.20 um 18:10 schrieb Christo Crause via fpc-devel: I've noticed some Xtensa support appear in trunk. This is exiting news for me. Are there some plans/ideas in terms of linking to existing frameworks such as Espressif's SDKs or Ultibo? Espressif SDK is work in progress and I got it it already working to a certain degree, actually. The main effort is currently spent into an xtensa-freertos target which is bascially using the Espressif SDK. Not everything is committed to trunk yet, but it will appear there step by step the next days. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Support for AVR subarch avrxmega3 (megaAVR 0, tinyAVR 0/1 series)
I just saw that trunk was updated, thank you for providing trunk support for avr atmega4808/09 chips! Michael Am 25.01.20 um 22:08 schrieb Florian Klämpfl: Am 22.01.20 um 18:25 schrieb Christo Crause via fpc-devel: On a related note, I have some developer board aliases from Michael (R) and Dimitrios. The board names are defined as new controllers, but the controllerunitstr has the name of the on-board controller. An example for Arduino Uno (popular hobbyist board): controllertypestr:'ARDUINOUNO'; controllerunitstr:'ATMEGA328P'; Would these kind of aliases be allowed in cpuinfo? I guess it would help hobbyist beginners that only know the name of a board to have a slightly easier start in FPC. I think it is fine. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] riscv32 and interrupts
Perhaps someone can help me with interrupts on riscv32: I have now changed the compiler to create proper interrupt routines, all used registers are saved on stack, so far so good: MTIP_ISR: .Lc2: sw x1,-4(x2) sw x8,-8(x2) sw x10,-12(x2) sw x11,-16(x2) addi x8,x2,0 *addi x2,x2,-68* .La1: auipc x10,%pcrel_hi(U_$P$TEST_$$_SYSTICKCOUNTER) addi x10,x10,%pcrel_lo(.La1) lw x11,0(x10) addi x11,x11,1 sw x11,0(x10) *addi x2,x8,0* lw x11,-16(x2) lw x10,-12(x2) lw x8,-8(x2) lw x1,-4(x2) mret but I am a little uncertain with stackframe size. For mipsel I did tweak function trv32procinfo.calc_stackframe_size:longint in cpupi.pas to increase the stackframe size so that the stackframe can hold all registers in worst case, when using interrupts also temp registers must be saved on stack when they are used. but in risc32 this function looks a lot different, I cannot see any handling of int registers, only float seems to be covered. calc_stackframe size is used to calc localsize in g_proc_exit, to better understand if I have covered all cases, how can I make localsize var > 0? From the generated code I see that in my example code localsize must have been <=0. I tried adding local vars to the interrupt routine but this did not change the generated code, only stackframe size was adjusted as expected so localsize must still have been <=0 Can you please point me in the right direction? Thank you, Michael Interrupt Routine with two local vars: MTIP_ISR: .Lc2: sw x1,-4(x2) sw x8,-8(x2) sw x10,-12(x2) sw x11,-16(x2) addi x8,x2,0 *addi x2,x2,-76* .La1: auipc x10,%pcrel_hi(U_$P$TEST_$$_SYSTICKCOUNTER) addi x10,x10,%pcrel_lo(.La1) lw x11,0(x10) addi x11,x11,1 sw x11,0(x10) lw x10,-56(x8) addi x10,x10,1 sw x10,-56(x8) lw x10,-56(x8) sw x10,-60(x8) *addi x2,x8,0* lw x11,-16(x2) lw x10,-12(x2) lw x8,-8(x2) lw x1,-4(x2) mret Pascal Version: procedure SysTick_interrupt; [interrupt, public, alias: 'MTIP_ISR']; var x : integer; y : integer; begin Inc(SysTickCounter); x := x+1; y := x; end; Am 12.01.20 um 01:04 schrieb Michael Ring: Here's my latest patch, I have included an (untested) unit for gd32vf103 chips The defines for interrupts should be correct, but I did not start testing if interrupts work. for the sifive chips the interrupts are definitively wrong, but this will be my next step to fix as I work more in the sifive board. Have fun, Michael Am 04.01.20 um 13:50 schrieb Michael Ring: The Boards are on their way, I found a second Sipeed MAIX board with a Kendryte K210 chip, this should cover the 64bit World. Shipping should take 3-5 days. I will see that I can come up with a prelimary unit-file for the K210 Have fun with the boards, Michael Am 03.01.20 um 20:13 schrieb Jeppe Johansen: Nice, thanks :) Jeppe Johansen Alexander Foss Gade 12, 3, 6 9000 Aalborg Denmark Hmm okay. Never seen a crash, but I haven't been using the 32bit toolchain that much Currently I use 2.32.51.20190629. Built from upstream d6954c38df90637bc1b0cc2b20473e2754e5eff7 Best Regards, Jeppe On 1/3/20 7:41 PM, Michael Ring wrote: I will be more than happy to provide a board to you Please send me you smail address, will send you a board. compiling now works fine with debuginfo but the linker crashes. Most likely a problem in my linker script, just to be sure, which binutils do you use? Michael Am 03.01.20 um 18:10 schrieb Jeppe Johansen: Hi Michael, I just fixed that. There was a very specific workaround in the fpc dwarf writer but only riscv*-linux was added, not embedded. I would be glad to buy a Longan Nano off you. Thought about getting those before but never got around to ordering some. Best Regards, Jeppe On 1/3/20 1:31 PM, Michael Ring wrote: Things are slowly progressing for me, there is one thing that bugs me, I cannot use Debug Info because I then get: Error: non-constant .uleb128 is not supported I found a few articles online on the issue and tried to replace my default riscv32-embedded-as (built from latest gnu binutils) with a version built out of the original risc-v git but this did not change a thing. Did you also encounter this? Which binutils package do you use? If you are interested then I can send you a logan nano, I bought three of them Happy new year, Michael Am 16.12.19 um 13:05 schrieb je...@j-software.dk: Hi Michael Looks like a good start. I have yet to get my hands on some actual boards but I'll probably get some sipeeed ones soon For the startup code the only tricky part is the initialization of the GP register. The rest(init
Re: [fpc-devel] Patch for AVR DWARF information
I can second that wish, It would be really great to have this patch in trunk, I use it successfully for a while now and debugging on avr is working as expected and increases productivity a lot. Michael Am 27.06.19 um 21:13 schrieb christo: Today is the anniversary of bug report 0033914. It took me a couple of tries, but I think I eventually arrived at a decent patch for this issue some time ago. Can I interest any of the core developers to evaluate this patch? Best regards, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR target on trunk does not compile for me
I set CROSSOPT to empty, after this change avr6 builds. BUT: What made me wonder was that avr5 builds fine, it should be affected by the same SOFTFPU issue. I did a quick grep through the fpc sources and found no obviously missing defines for avr6. However, a grep for avr revealed this code snippet in rtl/embedded/system.cfg: # AVR6 has normally more memory, so enable more functions #ifdef CPUAVR6 -SfANSISTRINGS -SfWIDESTRINGS -SfDYNARRAYS -SfTHREADING -SfVARIANTS -SfOBJECTS -SfCOMMANDARGS -SfRANDOM -SfRESOURCES #endif The build works find with -g when I remove -SfVARIANTS I am also wondering if CPUAVR is set when CPUAVR6 is set (I guess so), if this is true then -SfOBJECTS can also be removed from the CPUAVR6 Define as it is already in the CPUAVR define Last question: Is avr6 the only subarch that has enough memory for enabling strings? I am a Noob when it comes to avr, but I guess there should be more subarchs that have more memory, I today saw some ATTINY Chips with 32kB of Flash Michael Am 03.06.19 um 10:37 schrieb Jeppe Johansen: Probably because of the missing softfpu support. It's failing while writing debug info for floating point stuff in variants. It will be fixed some day :) On 6/2/19 10:54 PM, Michael Ring wrote: Thank you, not using -gw2 did the trick for avr5. Is this issue also known to you? I am trying to build avr6 support: BINUTILSPREFIX=avr- ; CROSSOPT="-O- -g -dDEBUG" SUBARCH=avr6 make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" || exit 1 sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX INSTALL_UNITDIR=/usr/local/lib/fpc/3.3.1/units/avr-embedded/$SUBARCH/rtl || exit 1 results in: /bin/mkdir -p /Users/ring/devel/fpc-avr/rtl/units/avr-embedded /Users/ring/devel/fpc-avr/compiler/ppcrossavr -Cpavr6 -Ur -Tembedded -Pavr -XPavr- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../avr -FE. -FU/Users/ring/devel/fpc-avr/rtl/units/avr-embedded -XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ -davr -dRELEASE -O- -g -dDEBUG -Us -Sg system.pp @system.cfg system.pp(293,1) Fatal: Internal error -1413909275 Michael Am 02.06.19 um 17:56 schrieb Christo Crause: On Sun, Jun 2, 2019 at 4:51 PM Michael Ring <mailto:m...@michael-ring.org>> wrote: I tried answering a question on the list today and to do so I did my 'first time ever' compile of the avr target. This is how I tried to build the avr-embedded target on my Mac: SUBARCH=avr5; BINUTILSPREFIX=avr- ; CROSSOPT="-O- -gw2 -dDEBUG" make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" || exit 1 [snip] /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s: Assembler messages: /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s:90477: Error: value of 68582 too large for field of 2 bytes at 4713 /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s:90485: Error: value of 68582 too large for field of 2 bytes at 4731 The compiler picks dwarf3 by default to avoid this type of problem, see also https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg35438.html Try building without specifying -gw2 in CROSSOPT. ___ fpc-devel maillist -fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist -fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR target on trunk does not compile for me
Thank you, not using -gw2 did the trick for avr5. Is this issue also known to you? I am trying to build avr6 support: BINUTILSPREFIX=avr- ; CROSSOPT="-O- -g -dDEBUG" SUBARCH=avr6 make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" || exit 1 sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX INSTALL_UNITDIR=/usr/local/lib/fpc/3.3.1/units/avr-embedded/$SUBARCH/rtl || exit 1 results in: /bin/mkdir -p /Users/ring/devel/fpc-avr/rtl/units/avr-embedded /Users/ring/devel/fpc-avr/compiler/ppcrossavr -Cpavr6 -Ur -Tembedded -Pavr -XPavr- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../avr -FE. -FU/Users/ring/devel/fpc-avr/rtl/units/avr-embedded -XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ -davr -dRELEASE -O- -g -dDEBUG -Us -Sg system.pp @system.cfg system.pp(293,1) Fatal: Internal error -1413909275 Michael Am 02.06.19 um 17:56 schrieb Christo Crause: On Sun, Jun 2, 2019 at 4:51 PM Michael Ring <mailto:m...@michael-ring.org>> wrote: I tried answering a question on the list today and to do so I did my 'first time ever' compile of the avr target. This is how I tried to build the avr-embedded target on my Mac: SUBARCH=avr5; BINUTILSPREFIX=avr- ; CROSSOPT="-O- -gw2 -dDEBUG" make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" || exit 1 [snip] /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s: Assembler messages: /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s:90477: Error: value of 68582 too large for field of 2 bytes at 4713 /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s:90485: Error: value of 68582 too large for field of 2 bytes at 4731 The compiler picks dwarf3 by default to avoid this type of problem, see also https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg35438.html Try building without specifying -gw2 in CROSSOPT. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] AVR target on trunk does not compile for me
I tried answering a question on the list today and to do so I did my 'first time ever' compile of the avr target. This is how I tried to build the avr-embedded target on my Mac: SUBARCH=avr5; BINUTILSPREFIX=avr- ; CROSSOPT="-O- -gw2 -dDEBUG" make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=$BINUTILSPREFIX OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" || exit 1 and failed miserably: /Users/ring/devel/fpc-avr/compiler/ppcrossavr -Cpavr5 -Ur -Tembedded -Pavr -XPavr- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../avr -FE. -FU/Users/ring/devel/fpc-avr/rtl/units/avr-embedded -XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ -davr -dRELEASE -O- -gw2 -dDEBUG -Us -Sg system.pp @system.cfg /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s: Assembler messages: /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s:90477: Error: value of 68582 too large for field of 2 bytes at 4713 /Users/ring/devel/fpc-avr/rtl/units/avr-embedded/system.s:90485: Error: value of 68582 too large for field of 2 bytes at 4731 . tons of more error messages I then switched to Christo's branch on github, used exactly the same commands and ended up with a successful build. Is there a chance to get the trunk for avr building again? https://github.com/ccrause/freepascal Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ENC28J60 Ethernet Controller AVR/ARM Driver
My 10 Cents on 'Embedded friendlyness': Objects and simple functions/procedures do not differ much in flash/memory usage as long as you do not use constructors/destructors. Calling your first constuctor adds arround 750 bytes of extra code (on avr platform). As those avr devices can have very low amount of flash i'd stay away from constuctors if possible.I'd also try to avoid virtual methods as the compiler will have to create a vmt and this will cost you precious RAM. Enhanced Records are also a good choice because you can save some bytes as the compiler can reuse the "self" parameter to address other fields in the record. This saves space on arm/mipsel targets where Devices like spi/uart/i2c are modeled as records and you usually address more than one register in a typical call to initialize or use the device. Last time I checked Enhanced Records also do not have constructors/vmt's (OK, not true for delphi...) so also no easy chance to waste that extra Flash/Ram on constuctors and vmt's. Besides those memory saving arguments here are some more ideas: When using Objects or advanced records you can simplify code that can use more than one communications protocol, e.g. those cheap OLED-Displays often are able to be driven via either SPI and I2C. When you create a thin layer on SPI/I2C then it is quite easy to support both protocols with low overhead and quite clean code for this kind of devices. From the "syntax candy" side of things I would definitely prefer Objects/Advanced Records over raw functions/procedures as you will get nice syntax help for all methods/properties as soon as you type the name of your instance in Lazarus. So what about classes? In a perfect world where everybody uses high performance 32bit microcontrollers (CortexM4/M7 chips from Microchip(Atmel)/ST/NXP) I would only use Classes and be happy forever, but unfortunately it seems that those 'big' chips, although beeing quite cheap (arround $10 to $40 for a very decent development board) do not catch that much attention, wonder why... And on all the small chips (LPC8xx/LPC11xx, AVR...,SAMD10/11) are absolutely not suited for classes as usage of classes will usually come with a high memory footprint , you will use all language features available and this requires you to often include additional units like sysutils which alone comes with a huge memory overhead and code generated for classes often includes hidden helpers that cost you extra CPU-Cycles and even more Flash. Also Classes ar instanciated on Heap, so you also need to include HeapMgr, not the biggest price to pay but anoher few k of flash are gone If you want to dig deeper i'd recommend to compile your code with the '-a' parameter, this parameter tells fpc to not delete the generated assembler files and simply by looking at those you get a good feel on what code is efficient and what code wastes cycles/flash like hell. So, to sum up, for me advanced records are currently the most efficient way to program microcontrollers, mainly because of my focus on smaller executables for the widest range of controllers, but depending on your requirements your mileage may vary. Michael Here's a lpi file to get you started in your investigations, you may need to change a few paths as they are unix specific Am 01.06.19 um 15:37 schrieb Dimitrios Chr. Ioannidis via fpc-devel: Hi, I started to write a driver ( https://github.com/dioannidis/fp_ethernet_enc28j60.git ) for this chip ( ENC28J60 Ethernet Controller ) first for the AVR platform, ( heavily inspired from the UIPEthernet library ( https://github.com/UIPEthernet/UIPEthernet.git )) and I want to ask the community, of course, is there anyone that already done it ? My goal is to made the free pascal users able to use a very low cost solution Arduino Nano / UNO development board with a ENC28J60 module for a little IoT ( and not only ) fun, learning e.t.c. ... I managed to configure the chip and the driver receives packets ( broadcast packets configured to allow only ARP ). Now, because I'm not embedded developer I'm thinking that I would need help / advices to take some decisions so here I am. First and more important, in the new FPC version, will the AVR platform review / resolve the following issues : "AVR - incorrect stack error checking" (https://bugs.freepascal.org/view.php?id=35332) "AVR - Assembler routines for 8, 16 & 32 bit unsigned div (code contribution)" ( https://bugs.freepascal.org/view.php?id=32103 ) "AVR - invalid address used when evaluating a variable in gdb" ( https://bugs.freepascal.org/view.php?id=33914 ) "AVR - Incorrect SPI clock rate bit constant names in
Re: [fpc-devel] Cortex-M0 (SAMD21G18A) and gcc-arm-none-eabi-8-2018-q4-major-win32
Quite a number is already in on trunk, but as the support for devices is getting bigger and bigger (at least on my harddisc) there is a need for an inteligent mechanism to handle the huge amount of devices as the header files eat up a lot of space in svn and only a very few will actually get used. Jeppe once had provided a nice mechanism to me but it never made it to trunk. From the last comment of Florian on the topic the door id open for implementing something that makes handling easier, but honestly I did not spend much time on this. Do you use a board like the Arduino Zero or do you work with plain, not pre-programmed chips? I am asking because in case you use Arduino Zero there will be some obstacles for you to get rid of the preinstalled bootloader that you will most likely have to face. Contact me in that case, I have already been down that road and have a working solution. (see https://learn.adafruit.com/proper-step-debugging-atsamd21-arduino-zero-m0/restoring-bootloader) Michael Am 27.05.19 um 12:53 schrieb Dimitrios Chr. Ioannidis via fpc-devel: Hi Michael, On 2019-05-26 14:14, Michael Ring wrote: Just one note of caution: When you encounter strange behaviour of your Code on Cortex-M0 in respect to DIV commmand then check the mailinglist, Jeppe has provided a fix but I am not quite sure if the fix has made it into official trunk. thx for the hint. By the way, any chance for inclusion your MCU definitions if official FPC ? regards, ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cortex-M0 (SAMD21G18A) and gcc-arm-none-eabi-8-2018-q4-major-win32
Just one note of caution: When you encounter strange behaviour of your Code on Cortex-M0 in respect to DIV commmand then check the mailinglist, Jeppe has provided a fix but I am not quite sure if the fix has made it into official trunk. Michael Am 26.05.19 um 09:15 schrieb Dimitrios Chr. Ioannidis via fpc-devel: Hi, yesterday I tried ( for first time ) to use the fpc for arm with the gcc-arm-none-eabi-8-2018-q4-major-win32 toolchain and I got this error : "G:\Programming\dimitris\tools\gcc-arm-none-eabi\bin\arm-none-eabi-objcopy.exe: G:\Programming\dimitris\tools\mbf\Samples\Blinky\Blinky.hex 64-bit address 0x4b4fa3 out of range for Intel Hex file" As I'm not familiar with ARM, does anyone have a clue or a hint on what I'm doing wrong ? FYI, FPC trunk builded with : ">make.exe clean crossall crossinstall OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv6m CROSSOPT="-O1" INSTALL_PREFIX=G:\Programming\dimitris\tools\fpc-trunk CROSSBINDIR=G:\Programming\dimitris\tools\gcc-arm-none-eabi\bin BINUTILSPREFIX=arm-none-eabi-" and the project options are : "G:\Programming\dimitris\tools\fpc-trunk\bin\x86_64-win64\fpc.exe -Tembedded -Parm -MObjFPC -Scgi -Ch8192 -Cs8192 -O1 -gw2 -l -vewnhibq -Fi..\..\Source -Filib\arm-embedded -Fu..\..\Source -Fu. -FUlib\arm-embedded -FE. -oBlinky -Cparmv6m -XParm-none-eabi- -Wparduinozero" PS: I used the "Microcontroller Board Framework" ( https://github.com/michael-ring/mbf ) from Michael Ring cause the official FPC doesn't have my MCU ( ATSAMD21G18A ). regards, -- Dimitrios Chr. Ioannidis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Compiler output for shr on Cortex-M4
Your patch did the trick, assembler Code is looking good now: pByte(@DR)^ := (aWord shr 8); 0800 187E LDR R0, [R11, #-0x38] 0800 1882 ADD.W R1, R0, #0xC 0800 1886 LDRH R0, [R11, #-0x30] 0800 188A UXTB R0, R0, ROR #8 0800 188E STRB R0, [R1] and my application also works fine now. This is a small demo of the issue: program shlissue; var MemoryAddress : pointer; aWord : word; begin aWord := $1000; pByte(MemoryAddress)^ := aWord shr 8; end. This compiles fine with your patch, shows the issue when compiled with unpatched fpc trunk Strange that you could not see the issue with -O1 I have also included an lpi file. When I open the lpi file in Lazarus it shows me optimizations set as O1. When I call lazbuild with --verbose then I get: CmdLine="/usr/local/bin/fpc -Tembedded -Parm -MObjFPC -Scgi -Ch8192 -Cs8192 -O1 -gw2 -l -vewnhibq -Fi/Users/ring/devel/mbf/Source -Fi/Users/ring/devel/mbf/Samples/shlissue/lib/arm-embedded -Fu/Users/ring/devel/mbf/Source -Fu/Users/ring/devel/mbf/Samples/shlissue/ -FU/Users/ring/devel/mbf/Samples/shlissue/lib/arm-embedded/ -FE/Users/ring/devel/mbf/Samples/shlissue/ -o/Users/ring/devel/mbf/Samples/shlissue/shlissue -Cparmv7em -XParm-none-eabi- -Wpnucleof401re -dnucleof401re shlissue.lpr" Thany you (again and again) for your help! Michael Am 05.02.19 um 21:09 schrieb Jeppe Johansen: I can only reproduce this with peephole optimization turned on (O2). Can you share more code that reproduces it? Either way here's a patch that might fix it? Best Regards, Jeppe On 2/3/19 5:31 PM, Michael Ring wrote: Forgot to mention I am using Trunk compiler from today revision 41187 ond optimization level was -O1 Michael Am 03.02.19 um 17:20 schrieb Michael Ring: I think I found another issue with Code generation, this time on Cortex-M4: I need to write Byte Aligned to the Data Register of the SPI Interface of a STM32 Chip so what I (try) to do is: using pByte(@DR)^ to force a single byte transfer and I succeed with the byte alignment... BUT please check the generated assembler, the requirred LSRS (SHR) is not done by the compiler. Just for fun I removed the byte alignment and the LSRS shows up... @Jeppe, can this have to do with the fix for Cortex-M0 you provided to me a few days ago or is this just another issue? pByte(@DR)^ := aWord shr 8; 0800 185A LDR R0, [R11, #-0x38] 0800 185E ADD.W R1, R0, #0xC 0800 1862 LDRH R0, [R11, #-0x30] 0800 1866 STRB R0, [R1] DR := aWord shr 8; 0800 1868 LDRH R0, [R11, #-0x30] 0800 186C LSRS R1, R0, #8 0800 186E LDR R0, [R11, #-0x38] 0800 1872 STR R1, [R0, #0xC] Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Compiler output for shr on Cortex-M4
Forgot to mention I am using Trunk compiler from today revision 41187 ond optimization level was -O1 Michael Am 03.02.19 um 17:20 schrieb Michael Ring: I think I found another issue with Code generation, this time on Cortex-M4: I need to write Byte Aligned to the Data Register of the SPI Interface of a STM32 Chip so what I (try) to do is: using pByte(@DR)^ to force a single byte transfer and I succeed with the byte alignment... BUT please check the generated assembler, the requirred LSRS (SHR) is not done by the compiler. Just for fun I removed the byte alignment and the LSRS shows up... @Jeppe, can this have to do with the fix for Cortex-M0 you provided to me a few days ago or is this just another issue? pByte(@DR)^ := aWord shr 8; 0800 185A LDR R0, [R11, #-0x38] 0800 185E ADD.W R1, R0, #0xC 0800 1862 LDRH R0, [R11, #-0x30] 0800 1866 STRB R0, [R1] DR := aWord shr 8; 0800 1868 LDRH R0, [R11, #-0x30] 0800 186C LSRS R1, R0, #8 0800 186E LDR R0, [R11, #-0x38] 0800 1872 STR R1, [R0, #0xC] Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Issue with Compiler output for shr on Cortex-M4
I think I found another issue with Code generation, this time on Cortex-M4: I need to write Byte Aligned to the Data Register of the SPI Interface of a STM32 Chip so what I (try) to do is: using pByte(@DR)^ to force a single byte transfer and I succeed with the byte alignment... BUT please check the generated assembler, the requirred LSRS (SHR) is not done by the compiler. Just for fun I removed the byte alignment and the LSRS shows up... @Jeppe, can this have to do with the fix for Cortex-M0 you provided to me a few days ago or is this just another issue? pByte(@DR)^ := aWord shr 8; 0800 185A LDR R0, [R11, #-0x38] 0800 185E ADD.W R1, R0, #0xC 0800 1862 LDRH R0, [R11, #-0x30] 0800 1866 STRB R0, [R1] DR := aWord shr 8; 0800 1868 LDRH R0, [R11, #-0x30] 0800 186C LSRS R1, R0, #8 0800 186E LDR R0, [R11, #-0x38] 0800 1872 STR R1, [R0, #0xC] Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] div creates wrong results on cortexm0
My basic testcase looks fine now and also the 'real' code now works as expected when I switch back from shr commands to div Thank you very much, Jeppe! Michael Am 26.01.19 um 15:20 schrieb Jeppe Johansen: Does the attached patch work? On 1/26/19 12:20 PM, Michael Ring wrote: I thought I was going crazy when debugging code that worked fine on cortex m3/4 but created unexpected results on cortex m0. Turns out that the compiler creates incorrect assembler code for cortexm0 for div when used with constant expressions. Optimization level was -O1 and -O- Take this code: program divtest; var a,b,c,d : word; begin a := 64; b := 8; c := a div 8; //.LI4 d := a div b; //.LI5 end. looking at the assembler code it is very evident that no shift operations are done on cortex m0 (see .LI4). Is this a known issue or should I create a new one in bugzilla? (Search did not reveal a hit that looked like a match) Michael assembler cortex m0: .Ll2: mov r1,#64 ldr r0,.Lj3 strh r1,[r0] .Ll3: mov r1,#8 ldr r0,.Lj4 strh r1,[r0] .Ll4: ldr r0,.Lj3 ldrh r0,[r0] uxth r0,r0 ldr r1,.Lj6 strh r0,[r1] .Ll5: ldr r0,.Lj3 ldrh r1,[r0] ldr r0,.Lj4 ldrh r0,[r0] bl fpc_div_longint uxth r0,r0 ldr r1,.Lj9 strh r0,[r1] assembler cortex m4: .Ll2: movs r1,#64 ldr r0,.Lj3 strh r1,[r0] .Ll3: movs r1,#8 ldr r0,.Lj4 strh r1,[r0] .Ll4: ldr r0,.Lj3 ldrh r0,[r0] asrs r1,r0,#31 add r0,r0,r1,lsr #29 asrs r0,#3 uxth r1,r0 ldr r0,.Lj6 strh r1,[r0] .Ll5: ldr r0,.Lj3 ldrh r0,[r0] ldr r1,.Lj4 ldrh r1,[r1] sdiv r0,r0,r1 uxth r0,r0 ldr r1,.Lj9 strh r0,[r1] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] div creates wrong results on cortexm0
I thought I was going crazy when debugging code that worked fine on cortex m3/4 but created unexpected results on cortex m0. Turns out that the compiler creates incorrect assembler code for cortexm0 for div when used with constant expressions. Optimization level was -O1 and -O- Take this code: program divtest; var a,b,c,d : word; begin a := 64; b := 8; c := a div 8; //.LI4 d := a div b; //.LI5 end. looking at the assembler code it is very evident that no shift operations are done on cortex m0 (see .LI4). Is this a known issue or should I create a new one in bugzilla? (Search did not reveal a hit that looked like a match) Michael assembler cortex m0: .Ll2: mov r1,#64 ldr r0,.Lj3 strh r1,[r0] .Ll3: mov r1,#8 ldr r0,.Lj4 strh r1,[r0] .Ll4: ldr r0,.Lj3 ldrh r0,[r0] uxth r0,r0 ldr r1,.Lj6 strh r0,[r1] .Ll5: ldr r0,.Lj3 ldrh r1,[r0] ldr r0,.Lj4 ldrh r0,[r0] bl fpc_div_longint uxth r0,r0 ldr r1,.Lj9 strh r0,[r1] assembler cortex m4: .Ll2: movs r1,#64 ldr r0,.Lj3 strh r1,[r0] .Ll3: movs r1,#8 ldr r0,.Lj4 strh r1,[r0] .Ll4: ldr r0,.Lj3 ldrh r0,[r0] asrs r1,r0,#31 add r0,r0,r1,lsr #29 asrs r0,#3 uxth r1,r0 ldr r0,.Lj6 strh r1,[r0] .Ll5: ldr r0,.Lj3 ldrh r0,[r0] ldr r1,.Lj4 ldrh r1,[r1] sdiv r0,r0,r1 uxth r0,r0 ldr r1,.Lj9 strh r0,[r1] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Where to set proper alignment default of const strings?
I see a fix in the bug description but I cannot see that it was
implemented on trun:
current trunk:
{ Align on native pointer size }
79 aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
80 dec(count,aligncount);
81
patch:
--- rtl/inc/generic.inc (revision 38836)
+++ rtl/inc/generic.inc (working copy)
@@ -59,7 +59,7 @@
then
begin
{ Align on native pointer size }
- aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
+ aligncount:=(sizeof(PtrUInt)-PtrInt(pdest)) and (sizeof(PtrUInt)-1);
dec(count,aligncount);
pend:=psrc+aligncount;
while psrc
Hi Michael,
there was a discussion in this issue
https://bugs.freepascal.org/view.php?id=33323
Cheers,
Benito
Am 28.11.18 um 19:51 schrieb Michael Ring:
The more I dig the more I ask myself if not the rtl routine is to
blame for the issue in the first place because it only takes
alignment of the destination into account when doing it's job.
Aligncount is calculated base on destination (which is RAM), for this
reason the last line always crashes because psrc can be unaligned.
I most likely completely misunderstand the meaning of
FPC_REQUIRES_PROPER_ALIGNMENT but usually ram can be written byte
aligned but flash has often limitations on read access so alignment
should look for psrc as this can come from flash.
Unless of course FPC_REQUIRES_PROPER_ALIGNMENT is primarily meant
for speed improovement only, then it would make sense to look at
pdest to try to optimize write performance by having as much aligned
access as possible.I only found an old discussion in lazarus list
from 2011 on this topic, where it looks like structs were manually
aligned in lazarus, but I did not look too deep into the patches.
procedure Move(const source;var dest;count:SizeInt);[public, alias:
'FPC_MOVE']; from generic.inc line77:
begin
{ Align on native pointer size }
--> *aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));*
dec(count,aligncount);
pend:=psrc+aligncount;
while psrc pptruint(pend):=pptruint(psrc)+(sizeuint(count) div
sizeof(ptruint));
while psrc
Hi,
I am debugging an issue that I see on mipsel embedded target (and
perhaps also on arm-embedded for corteX-m0, I had crashes in the
same rtl routine a while ago)
because RAM is small on embedded devices I use:
{$WRITEABLECONST OFF}
which means that const are read from flash and not from ram.
problem is now that const strings are sometimes not 32-bit aligned
and this causes an unaligned access exception on pic32mx because
date from flash must be read 32-bit aligned.
I thought that I had seen the correct place to configure this
alignment in the past but my google/grep foo is weak at the moment,
I cannot find something in the fpc sourcecode that rings a bell.
{$CODEALIGN CONSTMIN=4}
also does not work, I recompiled and in my case the const is still
improperly alligned.
Thanks in advance,
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist -fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Where to set proper alignment default of const strings?
After a little more fun in the debugger I came up with the following patch:
Index: generic.inc
===
--- generic.inc (revision 40381)
+++ generic.inc (working copy)
@@ -77,6 +77,8 @@
begin
{ Align on native pointer size }
aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
+ if aligncount > 0 then
+ aligncount := sizeof(PtrUInt)-aligncount;
dec(count,aligncount);
pend:=psrc+aligncount;
while psrcfrom my point of view the routine is wrongly calculating the numbers of
bytes that need to be read byte aligned before a pointer-sized copy can
be done
Michael
Am 28.11.18 um 19:51 schrieb Michael Ring:
The more I dig the more I ask myself if not the rtl routine is to
blame for the issue in the first place because it only takes alignment
of the destination into account when doing it's job.
Aligncount is calculated base on destination (which is RAM), for this
reason the last line always crashes because psrc can be unaligned.
I most likely completely misunderstand the meaning of
FPC_REQUIRES_PROPER_ALIGNMENT but usually ram can be written byte
aligned but flash has often limitations on read access so alignment
should look for psrc as this can come from flash.
Unless of course FPC_REQUIRES_PROPER_ALIGNMENT is primarily meant for
speed improovement only, then it would make sense to look at pdest to
try to optimize write performance by having as much aligned access as
possible.I only found an old discussion in lazarus list from 2011 on
this topic, where it looks like structs were manually aligned in
lazarus, but I did not look too deep into the patches.
procedure Move(const source;var dest;count:SizeInt);[public, alias:
'FPC_MOVE']; from generic.inc line77:
begin
{ Align on native pointer size }
--> *aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));*
dec(count,aligncount);
pend:=psrc+aligncount;
while psrc pptruint(pend):=pptruint(psrc)+(sizeuint(count) div
sizeof(ptruint));
while psrc
Hi,
I am debugging an issue that I see on mipsel embedded target (and
perhaps also on arm-embedded for corteX-m0, I had crashes in the same
rtl routine a while ago)
because RAM is small on embedded devices I use:
{$WRITEABLECONST OFF}
which means that const are read from flash and not from ram.
problem is now that const strings are sometimes not 32-bit aligned
and this causes an unaligned access exception on pic32mx because date
from flash must be read 32-bit aligned.
I thought that I had seen the correct place to configure this
alignment in the past but my google/grep foo is weak at the moment, I
cannot find something in the fpc sourcecode that rings a bell.
{$CODEALIGN CONSTMIN=4}
also does not work, I recompiled and in my case the const is still
improperly alligned.
Thanks in advance,
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Where to set proper alignment default of const strings?
The more I dig the more I ask myself if not the rtl routine is to blame
for the issue in the first place because it only takes alignment of the
destination into account when doing it's job.
Aligncount is calculated base on destination (which is RAM), for this
reason the last line always crashes because psrc can be unaligned.
I most likely completely misunderstand the meaning of
FPC_REQUIRES_PROPER_ALIGNMENT but usually ram can be written byte
aligned but flash has often limitations on read access so alignment
should look for psrc as this can come from flash.
Unless of course FPC_REQUIRES_PROPER_ALIGNMENT is primarily meant for
speed improovement only, then it would make sense to look at pdest to
try to optimize write performance by having as much aligned access as
possible.I only found an old discussion in lazarus list from 2011 on
this topic, where it looks like structs were manually aligned in
lazarus, but I did not look too deep into the patches.
procedure Move(const source;var dest;count:SizeInt);[public, alias:
'FPC_MOVE']; from generic.inc line77:
begin
{ Align on native pointer size }
--> *aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));*
dec(count,aligncount);
pend:=psrc+aligncount;
while psrc pptruint(pend):=pptruint(psrc)+(sizeuint(count) div
sizeof(ptruint));
while psrc
Hi,
I am debugging an issue that I see on mipsel embedded target (and
perhaps also on arm-embedded for corteX-m0, I had crashes in the same
rtl routine a while ago)
because RAM is small on embedded devices I use:
{$WRITEABLECONST OFF}
which means that const are read from flash and not from ram.
problem is now that const strings are sometimes not 32-bit aligned and
this causes an unaligned access exception on pic32mx because date from
flash must be read 32-bit aligned.
I thought that I had seen the correct place to configure this
alignment in the past but my google/grep foo is weak at the moment, I
cannot find something in the fpc sourcecode that rings a bell.
{$CODEALIGN CONSTMIN=4}
also does not work, I recompiled and in my case the const is still
improperly alligned.
Thanks in advance,
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Where to set proper alignment default of const strings?
Hi,
I am debugging an issue that I see on mipsel embedded target (and
perhaps also on arm-embedded for corteX-m0, I had crashes in the same
rtl routine a while ago)
because RAM is small on embedded devices I use:
{$WRITEABLECONST OFF}
which means that const are read from flash and not from ram.
problem is now that const strings are sometimes not 32-bit aligned and
this causes an unaligned access exception on pic32mx because date from
flash must be read 32-bit aligned.
I thought that I had seen the correct place to configure this alignment
in the past but my google/grep foo is weak at the moment, I cannot find
something in the fpc sourcecode that rings a bell.
{$CODEALIGN CONSTMIN=4}
also does not work, I recompiled and in my case the const is still
improperly alligned.
Thanks in advance,
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] MacOSX Mojave
A whilke ago I have proposed a fix in fpc-devel in Thread: "MacOS Mojave
beta - crt1.o not installed to /usr/lib"
Using the CommandLineTools directory (and not the XCode directory) makes
it possible to use fpc without the need to have the very huge xcode
installed, I deleted it a while ago and am happy since then.
Can you please check if this path also exists in your installation?
@CoreDevelopers, any change to merge this fix to trunk?
Michael
Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas (revision 39358)
+++ compiler/systems/t_bsd.pas (working copy)
@@ -377,7 +377,10 @@
if startupfile<>'' then
begin
if not librarysearchpath.FindFile(startupfile,false,result) then
- result:='/usr/lib/'+startupfile
+ if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+ else if
sysutils.fileexists('/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile)
then
+
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 06.10.18 um 16:01 schrieb C Western:
Possibly unwisely, I updated by Mac to Mojave. I found that things
(including 32 bit apps) worked, but:
I had to add
-Fl/Applications/Xcode.app/Con
tents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
to my fpc.cfg to avoid "/usr/lib/crt1.o not found" errors. It seems as
though the startup files are no longer in /usr/lib
The gdb from MacPorts also didn't seem to work. I had some success
using lldb - I notice an alpha package for this can be installed in
lazarus, and this seemed to work, at least on the basic test I did.
Colin
___
fpc-pascal maillist - fpc-pas...@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does mipsel-embedded build?
Most likely Jeppe sent the patch only to me, I have forwarded the patch to flor...@freepascal.org so that you can get an idea on what he did. Forgive me, I am a license dummy, can the licensing be handled properly with something like Jeppe's approach? If yes then I would love to maintain a repro of controller units, I can automagically generate Headers for most relevant microcontrollers currently available. Michael Am 30.09.18 um 19:53 schrieb Florian Klämpfl: Am 30.09.2018 um 19:48 schrieb Michael Ring: Hi Florian! I have already reduced size to the same size to the size as on other platforms, so a lot less space will be used. Please give me a little time to cleanup my patches... On providing headers seperate, a lnngg time ago Jeppe created a (close to genious) patch that allowed to use a configuration file to inject embedded controllers at runtime, but this never was implemented in trunk. True, I don't remember though were the patch was available. I have tons of .pas files for embedded controllers (complete STM Line, now also complete SAMC/SAMD line of controllers and PIC32) that I can all provide as a patch but this increases the emedded directory a lot and 95% of all headers will most likely never get used. Having the mechanism that Jeppe once developed would allow people to install just the files they need, keeping the embedded directory clean & lean. Perhaps this is something to implement in the future, what do you think? Yes, this could be done for sure. FYI, here are the current patches for SAMCD+STM32 family: https://github.com/michael-ring/mbf/tree/master/Patches Ah, now I remember the other problem with the controller units: they are BSD style licensed because of the license of the original headers, so we cannot include them into FPC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does mipsel-embedded build?
Hi Florian! I have already reduced size to the same size to the size as on other platforms, so a lot less space will be used. Please give me a little time to cleanup my patches... On providing headers seperate, a lnngg time ago Jeppe created a (close to genious) patch that allowed to use a configuration file to inject embedded controllers at runtime, but this never was implemented in trunk. I have tons of .pas files for embedded controllers (complete STM Line, now also complete SAMC/SAMD line of controllers and PIC32) that I can all provide as a patch but this increases the emedded directory a lot and 95% of all headers will most likely never get used. Having the mechanism that Jeppe once developed would allow people to install just the files they need, keeping the embedded directory clean & lean. Perhaps this is something to implement in the future, what do you think? FYI, here are the current patches for SAMCD+STM32 family: https://github.com/michael-ring/mbf/tree/master/Patches Michael Am 30.09.18 um 19:34 schrieb Florian Klämpfl: Am 30.09.2018 um 19:33 schrieb Michael Ring: Unfortunately a few files are missing in trunk, however I can provide patches to you to make things work, if you are in hurry then please send me an e-mail. I am currently working together with Alfred Glänzer (who does fpcupdeluxe) to integrate his port for Microchip SAMC/D controllers in my small framework for embedded controllers, next step after this is done will be to also better support PIC32 chips, so if you have a little time you will be able to use working support for PIC32 via fpcup deluxe. I can also provide the missing parts to the core defs to include those parts in trunk fpc if they are willing to do so. Of course, the only problem we need to handle are the huge controller specific files. But maybe those can be keep separate. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Does mipsel-embedded build?
Unfortunately a few files are missing in trunk, however I can provide patches to you to make things work, if you are in hurry then please send me an e-mail. I am currently working together with Alfred Glänzer (who does fpcupdeluxe) to integrate his port for Microchip SAMC/D controllers in my small framework for embedded controllers, next step after this is done will be to also better support PIC32 chips, so if you have a little time you will be able to use working support for PIC32 via fpcup deluxe. I can also provide the missing parts to the core defs to include those parts in trunk fpc if they are willing to do so. Michael Am 30.09.18 um 15:50 schrieb christo: I'm trying to understand how the RTL build process fits together. Looking at the makefile for embedded it seems that there may be a couple of files missing for mipsel-embedded. Firstly make complains about "no rule to make target mipsel/startup.s" probably because that file is missing from trunk (at least I cannot find it either). Secondly the cpu units such as pic32mx1xxfxxxb etc. are also missing. There is a comment for svn rev. 27188: "partially merged the mips-embedded branch from Michael Ring". I couldn't see any subsequent commits related to mipsel-embedded. Can anyone else build mipsel-embedded RTL with trunk? I've built ppcrossmipsel compiler so far. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM embedded for ATSAM
definitions for microcontrollers are available in the rtl/embedded/arm
directory, there is one (sometimes several) pascal file for a class of
microcontrollers of one vendor.
There is some light glue in the compiler/arm/cpuinfo.pas and
systems/t_embed.pas directory to make a new microcontroller available.
What I do is to auto-generate the main microcontroller file from the
header files of the microcontroller vendor.
On top of this you can then build your own library or extend pxl.
Michael
Am 07.09.18 um 12:45 schrieb Alfred:
Hello,
Intro.
After a long period of using C for writing firmware for Microchip
PIC24 and PIC32, I am now switching hardware and software.
For future projects, I will use:
* the Atmel/Microchip ATSAM series; these are Cortex M-0/3/4 MPU.
* FPC for writing the firmware.
First tests show a successful use of FPC on ATSAMD14 and ATSAMD21 and
ATSAMCx.
Sidenote.
As abstraction-layer, I use the pxl library.
See : https://asphyre.net/products/pxl
This library allows me to use apps, that access hardware, transparent
on nearly all platforms, including Ultibo.
Code using pxl will look like this:
const
PinLED = 9;
var
FGPIO : TCustomGPIO;
begin
FGPIO := TMicroGPIO.Create; //<- for arm embedded on ATSAM.
//FGPIO := TFastGPIO.Create; //<- for RPi running Linux.
FGPIO.PinMode[PinLED] := TPinMode.Output;
FGPIO.PinValue[PinLED] := TPinValue.High;
FGPIO.Destroy;
end;
Question.
There are many different ATSAM processors. All with many different
features and peripherals.
I would like to add (many of) them as embedded targets.
To prevent cluttering of directories, I propose to use small
definition units, that use include and switches to make a (rough)
differentiation between ATSAM-processors. The switches are used in the
include-files to filter features.
unit samd10c14;
{$define samd10c14}
interface
const
FLASH_SIZE = $4000; //* 16 kB */
FLASH_PAGE_SIZE = 64;
FLASH_NB_OF_PAGES = 256;
FLASH_USER_PAGE_SIZE = 64;
HMCRAMC0_SIZE = $1000; //* 4 kB */
{$i atmel/sam/sam-base.inc}
{$i atmel/sam/sam-irq.inc}
{$i atmel/sam/sam-ac.inc}
{$i atmel/sam/sam-adc.inc}
..
end;
The {$define samd10c14} is used in the include-files to enable/disable
features.
This allows for a very efficient re-use of code.
Would the above be acceptable to be included in FPC trunk ?
Or are there other (better) ways to add ATSAM embedded targets ?
Thanks for your advice.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib
Seems I misunderstood the meaning of "MacOSXVersionMin", it is set to
10.5 on my MacOS Mojave !!??!!
So the patch gets even more simple:
Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas (revision 39358)
+++ compiler/systems/t_bsd.pas (working copy)
@@ -377,7 +377,10 @@
if startupfile<>'' then
begin
if not librarysearchpath.FindFile(startupfile,false,result) then
- result:='/usr/lib/'+startupfile
+ if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+ else if
sysutils.fileexists('/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile)
then
+
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 01.07.18 um 23:31 schrieb Michael Ring:
This small patch helped me to get rid of the need to define
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ in /etc/fpc.cfg
It would be greet to have something similar in the upcoming 3.0.5
release (and of course in trunk) so that also building lazarus with a
3.0.5 compiler works (It currently fails without the entry in fpc.cfg)
Michael
Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas (revision 39358)
+++ compiler/systems/t_bsd.pas (working copy)
@@ -248,6 +248,9 @@
system_i386_darwin,
system_x86_64_darwin:
begin
+ { 10.14 and later: crt1.o }
+ if CompareVersionStrings(MacOSXVersionMin,'10.14')>=0
then
+ exit('crt1.so');
{ 10.8 and later: no crt1.* }
if CompareVersionStrings(MacOSXVersionMin,'10.8')>=0
then
exit('');
@@ -377,7 +380,10 @@
if startupfile<>'' then
begin
if not librarysearchpath.FindFile(startupfile,false,result) then
- result:='/usr/lib/'+startupfile
+ if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+ else if
sysutils.fileexists('/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/'+startupfile)
then
+
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 01.07.18 um 22:52 schrieb Michael Ring:
I only adjusted -Fl to match the current version installed, having a
wrong issue there did not change the build behaviour. The change
necessary was to include
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
otherwise fpcmake will not compile.
Cross-Compiling did however not work, the makefile of fpcmake does
seem to support FPCOPT but somehow the parameter does not get
forwarded to the makefile:
/Library/Developer/CommandLineTools/usr/bin/make -C utils/fpcm
bootstrap FPC=/Users/ring/devel/fpc-arm/compiler/ppcrossarm
FPCFPMAKE=/Users/ring/devel/fpc-arm/compiler/ppc RELEASE=1 'OPT='
results in:
/Users/ring/devel/fpc-arm/compiler/ppc fpcmake.pp -n
-Fu/Users/ring/devel/fpc-arm/rtl/units/x86_64-darwin
-FU/Users/ring/devel/fpc-arm/utils/fpcm/units/x86_64-darwin
ld: file not found: /usr/lib/crt1.10.5.o
An error occurred while linking
I could make crosscompiling work by doing this (Use OPT instead of
FPCOPT)
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi-
OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"
I hope that hardcoding the path
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will
solve this.
Thank you,
Michael
Am 01.07.18 um 22:34 schrieb Jonas Maebe:
On 01/07/18 22:18, Michael Ring wrote:
make clean buildbase CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/3.1.1
FPCOPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"
and patching my /etc/fpc.cfg to include:
#ifdef cpui386
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
both actions were needed for a successful compile...
What errors do you get if you don't include the -Fl option?
Is there a better way to make compiles work on Mojave?
The -XR above seems to be the correct way to handle this change. We
could also hard code that search path in the compiler in addition to
/usr/lib
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/
Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib
This small patch helped me to get rid of the need to define
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ in /etc/fpc.cfg
It would be greet to have something similar in the upcoming 3.0.5
release (and of course in trunk) so that also building lazarus with a
3.0.5 compiler works (It currently fails without the entry in fpc.cfg)
Michael
Index: compiler/systems/t_bsd.pas
===
--- compiler/systems/t_bsd.pas (revision 39358)
+++ compiler/systems/t_bsd.pas (working copy)
@@ -248,6 +248,9 @@
system_i386_darwin,
system_x86_64_darwin:
begin
+ { 10.14 and later: crt1.o }
+ if CompareVersionStrings(MacOSXVersionMin,'10.14')>=0 then
+ exit('crt1.so');
{ 10.8 and later: no crt1.* }
if CompareVersionStrings(MacOSXVersionMin,'10.8')>=0 then
exit('');
@@ -377,7 +380,10 @@
if startupfile<>'' then
begin
if not librarysearchpath.FindFile(startupfile,false,result) then
- result:='/usr/lib/'+startupfile
+ if sysutils.fileexists('/usr/lib/'+startupfile) then
+ result:='/usr/lib/'+startupfile
+ else if
sysutils.fileexists('/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/'+startupfile)
then
+
result:='/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/'+startupfile
end
else
result:='';
Am 01.07.18 um 22:52 schrieb Michael Ring:
I only adjusted -Fl to match the current version installed, having a
wrong issue there did not change the build behaviour. The change
necessary was to include
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
otherwise fpcmake will not compile.
Cross-Compiling did however not work, the makefile of fpcmake does
seem to support FPCOPT but somehow the parameter does not get
forwarded to the makefile:
/Library/Developer/CommandLineTools/usr/bin/make -C utils/fpcm
bootstrap FPC=/Users/ring/devel/fpc-arm/compiler/ppcrossarm
FPCFPMAKE=/Users/ring/devel/fpc-arm/compiler/ppc RELEASE=1 'OPT='
results in:
/Users/ring/devel/fpc-arm/compiler/ppc fpcmake.pp -n
-Fu/Users/ring/devel/fpc-arm/rtl/units/x86_64-darwin
-FU/Users/ring/devel/fpc-arm/utils/fpcm/units/x86_64-darwin
ld: file not found: /usr/lib/crt1.10.5.o
An error occurred while linking
I could make crosscompiling work by doing this (Use OPT instead of
FPCOPT)
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi-
OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"
I hope that hardcoding the path
/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will
solve this.
Thank you,
Michael
Am 01.07.18 um 22:34 schrieb Jonas Maebe:
On 01/07/18 22:18, Michael Ring wrote:
make clean buildbase CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/3.1.1
FPCOPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/"
and patching my /etc/fpc.cfg to include:
#ifdef cpui386
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
#ifdef cpux86_64
-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/
-Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0
#endif
both actions were needed for a successful compile...
What errors do you get if you don't include the -Fl option?
Is there a better way to make compiles work on Mojave?
The -XR above seems to be the correct way to handle this change. We
could also hard code that search path in the compiler in addition to
/usr/lib
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib
I only adjusted -Fl to match the current version installed, having a wrong issue there did not change the build behaviour. The change necessary was to include -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ otherwise fpcmake will not compile. Cross-Compiling did however not work, the makefile of fpcmake does seem to support FPCOPT but somehow the parameter does not get forwarded to the makefile: /Library/Developer/CommandLineTools/usr/bin/make -C utils/fpcm bootstrap FPC=/Users/ring/devel/fpc-arm/compiler/ppcrossarm FPCFPMAKE=/Users/ring/devel/fpc-arm/compiler/ppc RELEASE=1 'OPT=' results in: /Users/ring/devel/fpc-arm/compiler/ppc fpcmake.pp -n -Fu/Users/ring/devel/fpc-arm/rtl/units/x86_64-darwin -FU/Users/ring/devel/fpc-arm/utils/fpcm/units/x86_64-darwin ld: file not found: /usr/lib/crt1.10.5.o An error occurred while linking I could make crosscompiling work by doing this (Use OPT instead of FPCOPT) make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT="$CROSSOPT" BINUTILSPREFIX=arm-none-eabi- OPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" I hope that hardcoding the path /Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/ in FPC will solve this. Thank you, Michael Am 01.07.18 um 22:34 schrieb Jonas Maebe: On 01/07/18 22:18, Michael Ring wrote: make clean buildbase CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/3.1.1 FPCOPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" and patching my /etc/fpc.cfg to include: #ifdef cpui386 -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 #endif #ifdef cpux86_64 -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 #endif both actions were needed for a successful compile... What errors do you get if you don't include the -Fl option? Is there a better way to make compiles work on Mojave? The -XR above seems to be the correct way to handle this change. We could also hard code that search path in the compiler in addition to /usr/lib Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] MacOS Mojave beta - crt1.o not installed to /usr/lib
We've had this discussion (Jonas and me) a looong time ago (2013) with MacOS Maverics In the past, when xcode commandline tools was installed it created a link to crt1.10.5.o in /usr/lib. It now seems that this is not done anymore (at least not on my computer...) and as /usr/lib is write protected for root in newer versions of MacOSX it is not that easy to create a link by hand. The good news is that clang -print-search-dirs programs: =/Library/Developer/CommandLineTools/usr/bin libraries: =/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 returns a libraries path that helps finding a valid crt1.(10.5).o file: find /Library/Developer/CommandLineTools/ -name "crt1*" /Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/crt1.o /Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/crt1.10.5.o /Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/usr/lib/crt1.10.6.o I managed to get a successful compile by doing this: make clean buildbase CPU_TARGET=x86_64 INSTALL_PREFIX=$HOME/3.1.1 FPCOPT="-XR/Library/Developer/CommandLineTools//SDKs/MacOSX.sdk/" and patching my /etc/fpc.cfg to include: #ifdef cpui386 -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 #endif #ifdef cpux86_64 -XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -Fl/Library/Developer/CommandLineTools/usr/lib/clang/10.0.0 #endif both actions were needed for a successful compile... Is there a better way to make compiles work on Mojave? Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
The PIC32MX chips have one or two shadow sets, on the systems with only one shadow set it is hardcoded to the highest priority interrupt (7) I have implemented detection of shadow register use, in this case the registers do not get pushed on stack, that saves quite a few cpu-cycles in that case. But in a microcontroller systems you usually have several peripherals running at different interrupt levels, not so important tasks run on lower priorities so register saving is still an issue. Until now I did not look into floating point at all, as the small PIC32MX1/2 devices have no floating point processor I never used the real datatype anyway but when code for hardware floating point is always generated then this will of course create issues at runtime when somebody uses that datatype. But that's a story for another rainy day. Right now it is sufficient for me to know that it may be most likely a bug or an unimplemented feature (like sergej said), I was fearing that I did something wrong when defining the target. Perhaps in a future far far away I will look what it needs to also support PIC32MM and PIC32MZ but as they use MicroAdaptiv instruction set (something like thumb mode on arm) I will need to learn more on the inner workings of fpc so please bare with me when I continue asking questions on the inner working of fpc, I am slowly understanding more and more how things work but I still do not see the big picture Michael Am 24.08.16 um 10:09 schrieb Florian Klämpfl: Am 13.08.2016 um 18:57 schrieb Michael Ring: Hi! I am trying to bring interrupt handling routine size down (and speed up) for mipsel-embedded target. I need to use inline assembler routines like this one procedure TSystemCore.setCoreTimerComp(value : longWord); assembler; nostackframe; asm mtc0 $a1,$11,0 end ['a1']; inside of the interrupt handler, but as soon as I include the call to this procedure the number of registers that get saved explodes. When I only need to modify some peripheral I usually get away with only $v0 and $v1 registers getting saved, but with asm routine included all registers get saved. Same is true if I put the asm block directly inside of the interrupt handler. As you can see I have added the used registers list for this procedure so my expectation was that only the register declared does get added to the list of used registers. Is this a bug on mips platform or is there in general no way to define the list of used registers for an assembler routine so that register allocation works more efficient? Or is there another way for me to trick freepascal in not saving all registers? Did you read the suggestion from Michael Schnell? Does the MIPS you use have a shadow register set? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
I tried a small test program with -CfSoft or -CfMIPS2 or -CfMIPS3, result is always the same, I did a grep on the *.s files. I see allocations of float registers within the procedures, when they are called only cpu registers are marked as allocated. Michael Output: test.s:# Register v0 allocated test.s:# Register f2 allocated test.s:# Register v0 released test.s:# Register v0 allocated test.s:# Register v0 released test.s:# Register f0 allocated test.s:# Register f0 released test.s:# Register f2 released test.s:# Register v0 allocated test.s:# Register v1 allocated test.s:# Register v0,v1 released test.s:# Register a0 allocated test.s:# Register a0 released test.s:# Register v0 allocated test.s:# Register v0 released test.s:# Register a0 allocated test.s:# Register a0 released test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra allocated test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra released test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra allocated test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra released test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra allocated test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra released test.s:# Register v0 allocated test.s:# Register v0 released test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra allocated test.s:# Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra released test1.s: # Register a0 allocated test1.s: # Register a0 released test1.s: # Register v0 allocated test1.s: # Register f2 allocated test1.s: # Register v0 released test1.s: # Register v0 allocated test1.s: # Register v0 released test1.s: # Register f0 allocated test1.s: # Register f0 released test1.s: # Register f2 released Am 22.08.16 um 21:52 schrieb Florian Klämpfl: Am 21.08.2016 um 13:32 schrieb Michael Ring: Was getting high hopes for a moment... @Charlie: the last point you mention, this optimization is already there. As long as I do not call a procedure and directly include inline assembler in the interrupt routine all is fine, only really used registers are in the list of registers that need to get saved and the interrupt handlers gets quite lean & efficient. @Sergej: I just started wondering on usage of fp registers, when I call a routine that uses floating point I see that the fp registers are not marked as reserved by the compiler, what do you think? The procedure below (test) uses $f0 and $f2 but they are not marked as allocated: # Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra allocated jal P$TEST_$$_TEST nop # Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra released could this be a bug? (I have also modified tcpuparamanager.get_volatile_registers_fp to return [] so i'd expect to see $f0..$f19 pushed to stack but I see nothing) Soft float activated? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
Was getting high hopes for a moment... @Charlie: the last point you mention, this optimization is already there. As long as I do not call a procedure and directly include inline assembler in the interrupt routine all is fine, only really used registers are in the list of registers that need to get saved and the interrupt handlers gets quite lean & efficient. @Sergej: I just started wondering on usage of fp registers, when I call a routine that uses floating point I see that the fp registers are not marked as reserved by the compiler, what do you think? The procedure below (test) uses $f0 and $f2 but they are not marked as allocated: # Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra allocated jal P$TEST_$$_TEST nop # Register at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra released could this be a bug? (I have also modified tcpuparamanager.get_volatile_registers_fp to return [] so i'd expect to see $f0..$f19 pushed to stack but I see nothing) Could of course be me causing this bug, but I checked my diff to trunk, I have not knowingly changed fp behaviour besides changing get_volatile_registers_fp Michael procedure test; var b : real; begin b := sqrt(a); end; procedure test_interrupt; interrupt; var b : real; begin inc(a); asm nop end ['a0']; test; //b := round(a); end; Michael Am 21.08.16 um 12:25 schrieb Karoly Balogh (Charlie/SGR): Hi, On Sun, 21 Aug 2016, Sergei Gorelkin wrote: It is actually the opposite way around. g_save_registers/g_restore_registers methods are only used for first implemented targets (i386 and maybe m68k). All newer targets are written without calling them, since they are completely inappropriate to implement stack frame optimizations or push/pop-alike instructions for register saving. Well, they still have stubs in the HLCG, which is why I thought it must be newer than just dumping everything in g_proc_entry. Actually, I implemented them quite recently for 68k, and they're still routed in live code in psub.pas. However, since historically I missed the large compiler refactor in the mid-'00s, I believe you. Anyway... MIPS codegenerator does check which registers are actually used. The issue is, a procedure with 'interrupt' modifier must not modify any registers at all because it can be called asynchronously. As soon as an 'interrupt' procedure calls another (regular) procedure, the callee may modify any registers from volatile list, and the caller has no way to know which ones. Therefore, it has no other option than to save/restore all volatile registers. Well, one possible optimization would be to only save all volatiles if the interrupt routine actually calls another function. Otherwise only save the ones used by the current proc. This would allow some very small and very fast interrupt functions, right? I'm not sure though if there's an easy way to determine if there is a function call inside the function I'm generating code for. Maybe at the point of generating a function call, if the current proc is an interrupt, mark all volatiles as used somehow? Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
Thank you, your comments made me think (and write some more test code).
This is how I understand things right now:
The problem for Interrupt routines is that whenenever a procedure is
called the default list of Non-Volatile registers is allocated.
This is a no-issue in normal code as those registers never end up on the
stack because they get filtered out in g_proc_enter and g_proc_exit
For an interrupt things are a little different, all registers that get
touched need to get saved on the stack. So each time a procedure is
called in an interrupt routine the list of non-volatile registers gets
saved on the stack because for this case I changed
tcpuparamanager.get_volatile_registers_int() to return [].
So unless there is a way to find out which registers get used by a
procedure the only thing I can do to make interrupt routines as lean as
possible is to not use procedures in them if possible.
Fortunately inline assembler inside of the interrupt routine works just
fine (It seems I did something wrong when testing this):
The simple test program below saves only 3 registers on the stack when I
comment out the call of the procedure ($vo,$v1,$a0), the moment I remove
the comment the following registers get saved:
at,v0,v1,a0,a1,a2,a3,t0,t1,t2,t3,t4,t5,t6,t7,t8,t9,ra,fp and I guess I
must live with this fact.
But I am good with this because using inline assember in the interrupt
works and so I can streamline the interrrupt routines.
Thank you both for your valuable help,
Michael
program test;
{$MODE OBJFPC}
var
a : longWord;
procedure test;
begin
inc(a);
end;
procedure test_interrupt; interrupt;
begin
inc(a);
asm
nop
end ['a0'];
//test;
end;
begin
a := 0;
end.
Am 19.08.16 um 23:00 schrieb Jonas Maebe:
On 19/08/16 22:49, Michael Ring wrote:
Am 19.08.16 um 14:49 schrieb Jonas Maebe:
Michael Ring wrote on Sat, 13 Aug 2016:
I am trying to bring interrupt handling routine size down (and speed
up) for mipsel-embedded target.
I need to use inline assembler routines like this one
procedure TSystemCore.setCoreTimerComp(value : longWord); assembler;
nostackframe;
asm
mtc0 $a1,$11,0
end ['a1'];
Mentioning changed registers at the end of a pure assembler routine
has no effect. The compiler normally prints a warning about this. The
set of changed registers by a routine always only depends on its
calling convention. On most platforms we only support the official
ABI's calling convention, which is also the default.
I also tried also something like this:
procedure TSystemCore.setCoreTimerComp(value : longWord);
begin
asm
mtc0 $a1,$11,0
end ['a1'];
end;
with same result, all registers are saved. intead of only a few.
It is not clear what you mean by this. In your original message, you
said that all registers were saved "as soon as I include the call to
this procedure". As explained, the registers that are saved when
calling a routine only depend on what the ABI says are
volatile/callee-saved registers. Which registers are actually used by
the called routine have no influence at all.
Same is true if I put the asm block directly inside of the interrupt
handler.
In that case, the list of changed registers should be taken into
account. OTOH, using an inline assembler blocks disables the use the
use of register variables for that routine by the compiler, but that
should result in less registers getting saved rather than more.
Do you remember where this is coded or for what I should search in the
fpc sourcecode? Then I can try to find out what is going on in the mips
case.
It's the last part of the _asm_statement function in
compiler/pstatemnt.pas
FWIW, tcpuparamanager.get_volatile_registers_int() in mips/cpupara.pas
suggests that all integer registers except for R16-R23 are volatile,
so no matter what you do, if any of those registers contains a value
that is still needed after a call, they will be saved and restored.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
Am 19.08.16 um 14:49 schrieb Jonas Maebe: Michael Ring wrote on Sat, 13 Aug 2016: I am trying to bring interrupt handling routine size down (and speed up) for mipsel-embedded target. I need to use inline assembler routines like this one procedure TSystemCore.setCoreTimerComp(value : longWord); assembler; nostackframe; asm mtc0 $a1,$11,0 end ['a1']; Mentioning changed registers at the end of a pure assembler routine has no effect. The compiler normally prints a warning about this. The set of changed registers by a routine always only depends on its calling convention. On most platforms we only support the official ABI's calling convention, which is also the default. I also tried also something like this: procedure TSystemCore.setCoreTimerComp(value : longWord); begin asm mtc0 $a1,$11,0 end ['a1']; end; with same result, all registers are saved. intead of only a few. inside of the interrupt handler, but as soon as I include the call to this procedure the number of registers that get saved explodes. When I only need to modify some peripheral I usually get away with only $v0 and $v1 registers getting saved, but with asm routine included all registers get saved. If the ABI default calling convention states that a routine may change all registers, that is to be expected. Same is true if I put the asm block directly inside of the interrupt handler. In that case, the list of changed registers should be taken into account. OTOH, using an inline assembler blocks disables the use the use of register variables for that routine by the compiler, but that should result in less registers getting saved rather than more. Do you remember where this is coded or for what I should search in the fpc sourcecode? Then I can try to find out what is going on in the mips case. Thank you, Michael Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Revision 34338 breaks build on MacOSX
Error message is as below, happens on building trunk-fpc or trunk-crosscompilers for arm/mipsel /bin/mkdir -p mipsel/units/i386-darwin /Users/ring/devel/fpc-mipsel/compiler/ppc -Ur -Xs -O2 -n -Fumipsel -Fusystems -Fu/Users/ring/devel/fpc-mipsel/rtl/units/i386-darwin -Fimipsel -FE. -FUmipsel/units/i386-darwin -dRELEASE -dmipsel -dGDB -dBROWSERLOG -Fumips -Sew pp.pas Undefined symbols for architecture i386: "_IIDSTR_$SYSTEM_$$_IUNKNOWN$indirect", referenced from: _$$fpclocal$_ld42 in system.o _$$fpclocal$_ld46 in system.o "_IIDSTR_$SYSUTILS_$$_IREADWRITESYNC$indirect", referenced from: _$$fpclocal$_ld790 in sysutils.o _$$fpclocal$_ld793 in sysutils.o "_IIDSTR_$WPOBASE_$$_TWPOSECTIONREADERINTF$indirect", referenced from: _$$fpclocal$_ld10 in wpobase.o "_IIDSTR_$WPOBASE_$$_TWPOSECTIONWRITERINTF$indirect", referenced from: _$$fpclocal$_ld7 in wpobase.o "_IID_$SYSTEM_$$_IUNKNOWN$indirect", referenced from: _$$fpclocal$_ld42 in system.o _$$fpclocal$_ld46 in system.o "_IID_$SYSUTILS_$$_IREADWRITESYNC$indirect", referenced from: _$$fpclocal$_ld790 in sysutils.o _$$fpclocal$_ld793 in sysutils.o ld: symbol(s) not found for architecture i386 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
Hi! I am trying to bring interrupt handling routine size down (and speed up) for mipsel-embedded target. I need to use inline assembler routines like this one procedure TSystemCore.setCoreTimerComp(value : longWord); assembler; nostackframe; asm mtc0 $a1,$11,0 end ['a1']; inside of the interrupt handler, but as soon as I include the call to this procedure the number of registers that get saved explodes. When I only need to modify some peripheral I usually get away with only $v0 and $v1 registers getting saved, but with asm routine included all registers get saved. Same is true if I put the asm block directly inside of the interrupt handler. As you can see I have added the used registers list for this procedure so my expectation was that only the register declared does get added to the list of used registers. Is this a bug on mips platform or is there in general no way to define the list of used registers for an assembler routine so that register allocation works more efficient? Or is there another way for me to trick freepascal in not saving all registers? Thank you, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How do I find out which registers are actually used in an interrupt procedure and need to get pushed
This tip worked just fine, I was too blind to see how this works . Thank you Jonas! Michael Am 30.06.16 um 15:47 schrieb Jonas Maebe: Michael Ring wrote on Thu, 30 Jun 2016: So far I understood the fpc code that registers s0-s7 are automagically flagged when used as those are the registers that must be saved in the context of a standard procedure/function call. Same does apply for some of the Floating Point Registers. But when I look at the list of registers to be saved the registers like $v0 and $v1 are not included, but usually used. You'll probably want to modify tcpuparamanager.get_volatile_registers_(int/fpu) in compiler/mips/cpupara.pas based on the passed calloption. Volatile registers are registers that do not need to be saved by the callee according to the ABI, even if they are modified by the callee. For interrupt routines, you'll probably want to return an empty set there. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] How do I find out which registers are actually used in an interrupt procedure and need to get pushed
Hi! I am trying to make the interrupt keyword work for mipsel (to use with pic32mx) I have found the appropriate places in cgcpu.pas and I have the basics up and running, correct code for mipsel is generated. One issue I have at the moment is that I waste quite a number of precious memory for saving all standard and Floating-Point Registers of the CPU because I do not know which actually need saving. So far I understood the fpc code that registers s0-s7 are automagically flagged when used as those are the registers that must be saved in the context of a standard procedure/function call. Same does apply for some of the Floating Point Registers. But when I look at the list of registers to be saved the registers like $v0 and $v1 are not included, but usually used. Things get worse with floating point, there I also do not get info when e.g. $f2 is used, so I cannot decide if it is necessary to push the floatingpoint registers to the stack or to skip that step because no floating point is used in the interupt handler. For example: This simple code: procedure SysTick_interrupt; interrupt; [public, alias: 'CORE_TIMER_VECTOR_interrupt']; var // local1 : real; begin Inc(SysTickCounter, TSystemCore.TimerIntResolution); // local1 := SysTickCounter * 1.05; end; compiles to: .Ll2: lui $v0,%hi(TC_$MBF.SYSTEMCORE_$$_SYSTICKCOUNTER) lw $v0,%lo(TC_$MBF.SYSTEMCORE_$$_SYSTICKCOUNTER)($v0) addiu $v0,$v0,1000 lui $v1,%hi(TC_$MBF.SYSTEMCORE_$$_SYSTICKCOUNTER) sw $v0,%lo(TC_$MBF.SYSTEMCORE_$$_SYSTICKCOUNTER)($v1) so in this case only $v0,$v1 registers need to get pushed, no need to push any Floating Point Registers, but those two are not in the list of the used registers for this procedure When I uncomment the two lines in the example I additionally see that $f2 is used, but also not reported as used (which makes sense in the context of a normal procedure, but for an Interrupt Routine this means all the Flotingpoint registers need to be saved unconditionally as I cannot detect if floats are used. Any help & insight appreceated, Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] .long values in DWARF Symbols
Looking very good, I could load and debug a small app with a rtl built with -gw2 Thank you very much for the fix! I have now reduced the filesize of the embedded-units so that they should be small enough to be included in fpc: -rw-r--r-- 1 ring staff 33568 22 Mai 17:55 pic32mx1x0fxxxb.pp -rw-r--r-- 1 ring staff 33614 22 Mai 17:55 pic32mx1x0fxxxc.pp -rw-r--r-- 1 ring staff 33719 22 Mai 17:55 pic32mx1x0fxxxd.pp -rw-r--r-- 1 ring staff 40189 22 Mai 17:55 pic32mx1x0fxxxh.pp -rw-r--r-- 1 ring staff 40325 22 Mai 17:55 pic32mx1x0fxxxl.pp -rw-r--r-- 1 ring staff 39039 22 Mai 17:55 pic32mx2x0fxxxb.pp -rw-r--r-- 1 ring staff 39085 22 Mai 17:55 pic32mx2x0fxxxc.pp -rw-r--r-- 1 ring staff 39085 22 Mai 17:55 pic32mx2x0fxxxd.pp -rw-r--r-- 1 ring staff 45550 22 Mai 17:55 pic32mx2x0fxxxh.pp -rw-r--r-- 1 ring staff 45686 22 Mai 17:55 pic32mx2x0fxxxl.pp So I will have something to play with when traveling to Maker Faire in Hannover this weekend ;-) Michael Am 24.05.16 um 20:58 schrieb Florian Klämpfl: Am 23.05.2016 um 17:51 schrieb Michael Ring: I have started again to work on pic32 (mipsel-embedded) target and found an issue in the Dwarf Debug Info: (Please also refer to this old discussion on the problem: http://lists.freepascal.org/fpc-devel/2013-July/032447.html ) The problem is that .long should be replaced with .4byte for debug symbols to be correctly interpreted on mips. I manually replaced all .long with .4bytes in system.s and can now do symbolic debugging of the startup code There wrong entries always follow the pattern that they include an offset the the varname: Example: # Symbol THREADID .long U_$SYSTEM_$$_THREADID+4 --> wrong, offset is "+4" # Symbol UTF8COMPARELOCALE .4byte U_$SYSTEM_$$_UTF8COMPARELOCALE --> no offset, correct Can anybody help? Please try with r33782. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] .long values in DWARF Symbols
I have started again to work on pic32 (mipsel-embedded) target and found an issue in the Dwarf Debug Info: (Please also refer to this old discussion on the problem: http://lists.freepascal.org/fpc-devel/2013-July/032447.html ) The problem is that .long should be replaced with .4byte for debug symbols to be correctly interpreted on mips. I manually replaced all .long with .4bytes in system.s and can now do symbolic debugging of the startup code There wrong entries always follow the pattern that they include an offset the the varname: Example: # Symbol THREADID .long U_$SYSTEM_$$_THREADID+4 --> wrong, offset is "+4" # Symbol UTF8COMPARELOCALE .4byte U_$SYSTEM_$$_UTF8COMPARELOCALE --> no offset, correct Can anybody help? Michael # Symbol UTF8COMPARELOCALE .uleb1283 .ascii "UTF8COMPARELOCALE\000" .byte 1 .byte 5 .byte 3 .4byte U_$SYSTEM_$$_UTF8COMPARELOCALE .4byte DBG_$SYSTEM_$$_WORD # Symbol THREADID .uleb1283 .ascii "THREADID\000" .byte 1 .byte 5 .byte 3 .long U_$SYSTEM_$$_THREADID+4 .4byte DBG_$SYSTEM_$$_LONGINT # Symbol ERROUTPUT .uleb1283 .ascii "ERROUTPUT\000" .byte 1 .byte 5 .byte 3 .long U_$SYSTEM_$$_ERROUTPUT+4 .4byte DBG_$SYSTEM_$$_TEXT ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] trunk for arm-embedded does not compile anymore
TnX! Am 27.03.16 um 21:28 schrieb Marco van de Voort: In our previous episode, Michael Ring said: the following patch solves the issue, can someboby please apply? Applied. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] trunk for arm-embedded does not compile anymore
Builf fails with the following message:
/Users/ring/devel/fpc-arm/compiler/ppcrossarm -Cparmv7em @rtl.cfg -Ur
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FE. -FU/Users/ring/devel/fpc-arm/rtl/units/arm-embedded -darm
-dRELEASE -O2 -Fi../objpas/sysutils sysutils.pp
osutilsh.inc(32,10) Error: Forward declaration not solved
"ExecuteProcess(const RawByteString;const
RawByteString;TExecuteFlags=""):LongInt;"
osutilsh.inc(33,10) Error: Forward declaration not solved
"ExecuteProcess(const RawByteString;const {Open} Array Of
RawByteString;TExecuteFlags=""):LongInt;"
osutilsh.inc(34,10) Error: Forward declaration not solved
"ExecuteProcess(const UnicodeString;const
UnicodeString;TExecuteFlags=""):LongInt;"
osutilsh.inc(35,10) Error: Forward declaration not solved
"ExecuteProcess(const UnicodeString;const {Open} Array Of
UnicodeString;TExecuteFlags=""):LongInt;"
sysutils.pp(280) Fatal: There were 4 errors compiling module, stopping
Fatal: Compilation aborted
make[3]: *** [sysutils.ppu] Error 1
make[2]: *** [embedded_all] Error 2
make[1]: *** [rtl_all] Error 2
make: *** [base.build-stamp.arm-embedded] Error 2
the following patch solves the issue, can someboby please apply?
TnX,
Michael
svn diff fpc-arm/rtl/embedded/sysutils.pp
Index: fpc-arm/rtl/embedded/sysutils.pp
===
--- fpc-arm/rtl/embedded/sysutils.pp(revision 33349)
+++ fpc-arm/rtl/embedded/sysutils.pp(working copy)
@@ -255,18 +255,25 @@
end;
-function ExecuteProcess (const Path: AnsiString; const ComLine:
AnsiString;Flags:TExecuteFlags=[]): integer;
+function ExecuteProcess(Const Path: RawByteString; Const ComLine:
RawByteString;Flags:TExecuteFlags=[]):integer;
begin
result := -1;
end;
+function ExecuteProcess(Const Path: RawByteString; Const ComLine: Array
of RawByteString;Flags:TExecuteFlags=[]):integer;
+begin
+ result := -1;
+end;
-function ExecuteProcess (const Path: AnsiString;
- const ComLine: array of
AnsiString;Flags:TExecuteFlags=[]): integer;
+function ExecuteProcess(Const Path: UnicodeString; Const ComLine:
UnicodeString;Flags:TExecuteFlags=[]):integer;
begin
result := -1;
end;
+function ExecuteProcess(Const Path: UnicodeString; Const ComLine: Array
of UnicodeString;Flags:TExecuteFlags=[]):integer;
+begin
+ result := -1;
+end;
{
Initialization code
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
