[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
[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 of .data and .bss) can be done as Pasc
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
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] 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] 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
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
[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] 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
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?
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?
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
[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] 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
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] 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] 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
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
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
[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] 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
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
[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
[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] 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] 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
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
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
[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] 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
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
[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] 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
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
[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
[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
+
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
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
[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
[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] 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
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] 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
[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
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] 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] 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] 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] 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
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
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
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] 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] 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
[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
[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
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
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
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
[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] 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] Fix compile error for armv6m target
There's a syntax error that is in trunk for a while now, here's the fix,
can anybody of the dev's please apply this?
Michael
ring@MacbookPro fpcsrc $ git diff rtl/arm/thumb.inc
diff --git a/rtl/arm/thumb.inc b/rtl/arm/thumb.inc
index 85d948a1e1..c7a9273be1 100644
--- a/rtl/arm/thumb.inc
+++ b/rtl/arm/thumb.inc
@@ -99,7 +99,7 @@ function InterLockedExchangeAdd (var Target:
longint;Source : longint) : longint
function InterlockedCompareExchange(var Target: longint; NewValue:
longint; Comperand: longint): longint;
{$else VER3_2}
{$define FPC_SYSTEM_HAS_ATOMIC_CMP_XCHG_32}
-function fpc_atomic_cmp_xchg_32(var Target: longint; NewValue; longint;
Comparand: longint): longint; [public,alias:'FPC_ATOMIC_CMP_XCHG_32'];
+function fpc_atomic_cmp_xchg_32(var Target: longint; NewValue: longint;
Comparand: longint): longint; [public,alias:'FPC_ATOMIC_CMP_XCHG_32'];
{$endif VER3_2}
begin
Result:=Target;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] cnetdb.pp Compile Error on both trunk and stable (MacOSX aarch64)
When trying to build fpc (with fpcupdeluxe) I get the following error
for both Trunk and Stable(!!) version of fpc:
Compiling ./fcl-net/src/cnetdb.pp
cnetdb.pp(240,2) Error: User defined: fatal 'Please consult the netdb.h
file for your system to determine the order of ai_addr and ai_canonname'
cnetdb.pp(320,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
problem is that none of the defines matches:
{$if defined(LINUX) or defined(OPENBSD)}
{$define FIRST_ADDR_THEN_CANONNAME}
{$endif}
{$if defined(FREEBSD) or defined(NETBSD) or defined(DRAGONFLY) or
defined(SOLARIS) or defined(ANDROID)}
{$define FIRST_CANONNAME_THEN_ADDR}
{$endif}
{$if not defined(FIRST_CANONNAME_THEN_ADDR) and not
defined(FIRST_ADDR_THEN_CANONNAME)}
{$error fatal 'Please consult the netdb.h file for your system to
determine the order of ai_addr and ai_canonname'}
{$endif}
Any help appreciated,
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
