[fpc-devel] Handling controllers with different floating point capabilities but the same subarch
Work is under way to include more controllers supported by the esp-idf SDK. There are currently three xtensa controllers esp32 (lx6), esp32s2 (lx7) and esp32s3 (lx7), where the esp32s2 does not have hardware floating point support, while the esp32 and esp32s3 do. Since the esp32s2 and esp32s3 are part of the same subarch, one cannot specify a floating point option for the subarch, since the one controller does not support it. Would it make sense to move the esp32s3 controller to a new subarch (lx7hf), so that the -Cfhard option can be specified in the MakeFile for freertos target? And if accepted, should the esp32 subarch be changed to lx6hf to be consistent in nomenclature? How would this affect the xtensa-linux target? Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible bug in "chmreader"
Hi Kit, fwindowslist is created in the constructor, which may explain why this bug is dormant. I assume this is supposed to be a defensive check, although fwindowslist is also accessed later in this method without a safety check. Perhaps the "if not? assigned()" check can be omitted since it isn't sufficient protection and the constructor should have automatically created the fwindowslist class. My 2 cents... On Wed, Feb 21, 2024 at 12:16 PM J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi everyone, > > While evaluating a new peephole optimisation, I came across a null > pointer dereference in the assembly language. After looking at the > original Pascal code, I came across this starting at line 525 of > packages/chm/src/chmreader.pas: > > procedure TChmReader.ReadWindows(mem:TMemoryStream); > > var >i,cnt, >version : integer; >x : TChmWindow; > begin > if not assigned(fwindowslist) then > fWindowsList.Clear; > mem.Position:=0; > ... > > This code looks very suspicious to me because it calls > fWindowsList.Clear only if fWindowsList is a null pointer. This will > instantly cause an access violation (Clear is not a class method). > > Without the new optimisation, this is what the x86_64-win64 assembly > language looks like: > > cmpq$0,280(%rbx) > jne.Lj189 > movq280(%rbx),%rcx > movq(%rcx),%rax > call*216(%rax) > .Lj189: > > If JNE doesn't branch, then the value at 280(%rbx) is zero, and this is > then copied into %rcx, then the value referenced by %rcx is stored in > %rax, however because the value at 280(%rbx) is zero, then %rcx is also > zero and (%rcx) is a null pointer dereference. > > Kit > > ___ > 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] Cannot create Merge Request
On Thu, Jan 4, 2024 at 6:18 AM Amir--- via fpc-devel wrote: > > I do not see the option to upload attach the patch file? In GitLab, scroll down to the bottom of the page showing your issue. There should be an edit box where you can type a new comment. You can also drag and drop a file into this box, or click on the paperclip icon to attach a file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cannot create Merge Request
On Wed, Jan 3, 2024 at 8:38 AM Amir--- via fpc-devel wrote: > I never used gitlab before, so my question might be very stupid! > I am trying to follow the instruction here to create a patch. I have created > a Feature Request but cannot figure out how to create a MergeRequest? A merge request is different to a patch. A patch is (in my mind at least) a static difference between two files or sets of files. You still need a tool to retrieve a copy of the main branch, keep this copy up to date with the official git repository (to potentially include changes by others) and keep your changes in sync with the moving target of the main branch. Git can create patches (via the git diff command), but this is a static snapshot. It is more elegant (IMHO) to create a clone of FPC on GitLab, create a branch for your modifications, and use GitLab to automatically generate a merge request. Some basic git concepts are described here: https://wiki.lazarus.freepascal.org/FPC_git At the end of that wiki page there is a section that describes the typical workflow of how to go about creating a merge request for FPC. This may seem like extra effort initially, but if you are planning on contributing more than one merge request it will make sense in the long run. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LEA instruction speed
On Tue, Oct 10, 2023 at 11:13 AM J. Gareth Moreton via fpc-devel wrote: > > Thanks Tomas, > > Nothing is broken, but the timing measurement isn't precise enough. > > Normally I have a much higher iteration count (e.g. 1,000,000), but I > had reduced it to 10,000 because, coupled with the 1,000 iterations in > the subroutines themselves, would have led to 1,000,000,000 passes and > hence would take in the region of five to ten minutes to complete for a > 16 MHz 386, for example. Rika's suggestion of running as many > iterations as needed until, say, 5 seconds elapses, would help but the > timing measurements would cause a lot of latency and will be imprecise > on very slow routines. Still, let's see if 100,000 gives better results > for you. > > Kit Results on a modest CPU: CPU = Intel(R) Celeron(R) CPU N3050 @ 1.60GHz - Pascal control case: 6.71 ns/call Using LEA instruction: 2.09 ns/call Using ADD instructions: 2.05 ns/call 32 bits: Pascal control case: 6.78 ns/call Using LEA instruction: 2.16 ns/call Using ADD instructions: 2.09 ns/call Results show a bit of variance, above numbers are more or less typical. Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Merge fix for Fpmmap offset in fixes branch?
Will fix 17158c35 (mmap2 expects that offset is divided by 4096) be merged with the fixes branch? I encountered this problem on a Raspberry Pi when remapping the GPIO memory. space. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] rtl_do_close is not called in the embedded and freertos targets
On Tue, Aug 22, 2023 at 8:05 AM Kostas Michalopoulos via fpc-devel wrote: > I was looking at the RTL code to see if the embedded target could be > used as a workaround for unsupported OSes (e.g. some custom kernel) and > noticed that there are some global function pointers used as callbacks > for system-specific functionality - which is neat. > > However i also noticed that the do_close procedure in sysfile.inc > doesn't do anything (it is empty) and nothing calls the rtl_do_close > callback (the other do_xxx procedures do call the equivalent rtl_do_xxx > if they are set). I don't have any actual program to test that out, it > was just something i noticed by reading the code but it seems like a bug > to me as i can't see a way to close a file handle otherwise. For what it's worth, I agree with your assessment. Obviously file handling is not used or tested much with embedded/freeRTOS targets. I suggest creating a pull request with your fix. Best regards, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Redundant init_final_table record generated for targets with the tf_init_final_units_by_calls flag?
I have noticed that embedded targets generate code for initialize/finalize functionality by overriding the insert_init_final_table class method. However at the end of the overridden method, the parent insert_init_final_table method is also called, which generates an initfinal table which isn't called anywhere (AFAICS). Is there some case where the initfinal table is actually required, or can the inherited call be removed for these targets? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler optimization techniques
On Sat, Mar 25, 2023 at 2:36 AM Wayne Sherman via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Explaining my fast 6502 code generator > "To learn how optimizing compilers are made, I built one targeting the > 6502 architecture. In a bizarre twist, my compiler generates faster > code than GCC, LLVM, and every other compiler I compared it to..." > > https://pubby.games/codegen.html > An interesting read, thank you for sharing this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An interesting thought... AI
On Thu, Nov 10, 2022 at 8:10 PM J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi everyone, > > This has been something that has been on my mind for a while now, but > with my increasingly more complex optimisations being developed for the > Free Pascal Compiler and the code becoming an ever bigger spiderweb of > conditions, it got me to start wondering... might compiler optimisation > be a candidate for AI? > An interersting thought. On a slightly different tangent, could the language rules itself not be codified as a matrix so that one can use matrix algebra to perform node level optimizations via similarity transforms? Alternatively, if you want to test a candidate optimization idea, check if there is a feasible solution using matrix algebra (in other words check if it satisfies all the language rules and the original intent). My simplistic view of Pascal is that the language rules should form a set of linear equations (else the language specification is overly complicated), so linear algebra is ideal for checking if a potential solution satisfies the language rules. Also one could cast a node level optimization as a (similarity?) transformation matrix and apply this to the basic nodes generated by the parser. So there is perhaps some scope for "simple" algebra before diving into stochastic optimization techniques. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of ESP8266 embedded target
On Tue, Oct 4, 2022 at 7:29 AM Travis Siegel wrote: > On 10/4/2022 1:07 AM, Christo Crause wrote: > > On Tue, 4 Oct 2022, 01:15 Travis Siegel via fpc-devel, < > fpc-devel@lists.freepascal.org> wrote: > >> Does this process use gcc to do the compile, instead of fpc directly? If >> it does, I will dig into making it compatible with Parallax's line of >> propeller boards, since it now supports GCC to generate code for the >> propeller 1 and 2 boards. Being able to program these in pascal would >> be wonderful. Parallax has a series of SBC products, including the >> basic stamp, a java stamp, (no longer produced), and as mentioned, the >> propeller boards. They also have several robot packages that can be >> programmed via the propeller or basic stamps, so if the esp board code >> does work, and it calls gcc for it's work, I'll certainly be interested >> in tackling making it work with the propeller boards, I think that could >> help some folks start using those boards. >> > > The compiler typically generates target CPU specific assembler code, which > requires an external assembler and linker to generate the executable code. > I don't know much about the Parallax controllers, but it appears to be a > distinct architecture (not ARM or MIPS for example) not yet supported by > FPC, so would require a new compiler backend AFAIU. > > > Yeah, it's a custom board, but it has 8 cores, which makes multitasking > real simple. They call them cogs, and you can spin up another cog at any > time. It also uses a language called spin (their version of assembly), so > I guess it could be supported, but how much work is adding a whole new > architecture to FPC? > For someone who is familiar with the compiler design, adding a new architecture would be easy but would probably still take a few weeks worth of effort. This assumes existing knowledge of the low level functioning of the target. I have patched a few bugs in the past, but it took me many days to figure out how seemingly simple functionality integrated into the overall compiler design. It would probably be worthwhile to get a compiler developer interested in this exercise from the start to help speed up the effort. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of ESP8266 embedded target
On Tue, 4 Oct 2022, 01:15 Travis Siegel via fpc-devel, < fpc-devel@lists.freepascal.org> wrote: > Does this process use gcc to do the compile, instead of fpc directly? If > it does, I will dig into making it compatible with Parallax's line of > propeller boards, since it now supports GCC to generate code for the > propeller 1 and 2 boards. Being able to program these in pascal would > be wonderful. Parallax has a series of SBC products, including the > basic stamp, a java stamp, (no longer produced), and as mentioned, the > propeller boards. They also have several robot packages that can be > programmed via the propeller or basic stamps, so if the esp board code > does work, and it calls gcc for it's work, I'll certainly be interested > in tackling making it work with the propeller boards, I think that could > help some folks start using those boards. > The compiler typically generates target CPU specific assembler code, which requires an external assembler and linker to generate the executable code. I don't know much about the Parallax controllers, but it appears to be a distinct architecture (not ARM or MIPS for example) not yet supported by FPC, so would require a new compiler backend AFAIU. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [AVR] Debugging objects
On Sat, Sep 24, 2022 at 9:41 AM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > >it seems that there is another DWARF bug regarding objects in units. > 8< (gdb) s > UTESTOBJs_sTTESTOBJ_s__ss_DOSOMETHING () at utestobj.pas:16 > 16x := 5; > (gdb) print x > No symbol "x" in current context. > > I can confirm the same problem with FPC main. The problem is also present in FPC 3.2.2 on Linux 64 bit. Looking at the debug info suggests that the information for the DoSomething method is omitted when declaring an object type, but with advanced records the method info is emitted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of ESP8266 embedded target
On Mon, Sep 19, 2022 at 8:52 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 19.09.22 um 08:10 schrieb Christo Crause via fpc-devel: > > I'm trying to get a minimal embedded example working, but there seems to > > be some issues with the linker script and the startup code. Is there a > > working (simple) example I can study? Or are further tweaks needed to > > get the embedded target working for ESP8266? > > Not sure if it ever worked. I guess you looked already at the (little) > information in the wiki? > Thanks, I suspected the current state wasn't quite working, just wanted to make sure I'm not missing something obvious. This probably explains why the xtensa-embedded section on the wiki is empty. I managed to get a simple message printed over serial and blink an LED, so there is a bit of progress. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Status of ESP8266 embedded target
I'm trying to get a minimal embedded example working, but there seems to be some issues with the linker script and the startup code. Is there a working (simple) example I can study? Or are further tweaks needed to get the embedded target working for ESP8266? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smart-linking on linux/x86-64
On Tue, Jul 5, 2022 at 11:45 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > I think many people would be glad if you'd solve the issue of smart > linking with debug information when an external linker is used. :) > > Regards, > Sven > >> Indeed, a similar problem exists for AVR: https://gitlab.com/freepascal.org/fpc/source/-/issues/39825 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Question on IsMemoryManagerSet logic
Trying to detect at unit initialization if a memory manager has been
installed (xtensa-freertos) fails on FreeRTOS target. It appears that
IsMemoryManagerSet[1] always returns false for this target, even if a
custom memory manager has been installed. Looking at the implementation of
IsMemoryManagerSet shows that it will always return false if either
HAS_MEMORYMANAGER or FPC_NO_DEFAULT_MEMORYMANAGER is defined, if none of
these are defined, it will check if the getmem & freememare different to
the system defined routines.
For FreeRTOS both HAS_MEMORYMANAGER and FPC_NO_DEFAULT_MEMORYMANAGER are
defined, so it is impossible to detect if a custom memory manager has been
installed using IsMemoryManagerSet.
a) Am I using the correct approach to detect if a memory manager is
installed? I want to check if it is safe to use GetMem/FreeMem.
b) Is there a reason for the behaviour of IsMemoryManagerSet?
[1] From rtl/inc/heap.inc:
function IsMemoryManagerSet:Boolean;
begin
{$ifdef HAS_MEMORYMANAGER}
Result:=false;
{$else HAS_MEMORYMANAGER}
{$ifdef FPC_NO_DEFAULT_MEMORYMANAGER}
Result:=false;
{$else not FPC_NO_DEFAULT_MEMORYMANAGER}
IsMemoryManagerSet := (MemoryManager.GetMem<>@SysGetMem)
or (MemoryManager.FreeMem<>@SysFreeMem);
{$endif notFPC_NO_DEFAULT_MEMORYMANAGER}
{$endif HAS_MEMORYMANAGER}
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Plans for 2022
On Sun, Jan 9, 2022 at 9:09 AM J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Some people requested a Patreon post as to my plans for 2022 with FPC, > so I was happy to oblige. Plans may change a bit though depending on > what happens in life and also what Florian's own vision is with the > compiler, but this is the gist of it: > > https://www.patreon.com/posts/60922821 > > Gareth aka. Kit > An interesting read Gareth.thank you for sharing. It would be really nice to have such roadmaps (or at least visions) from everyone working on the compiler/rtl/packages, and also the roadmap from the core team for the future plans for FPC. This is obviously more than just a trivial amount of work, and there is no guarantee that all the fringe contributors will suddenly harmonize with the core team's vision, but I hope it will generate a slightly more concerted effort to move the project forward. Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assembler file option (-a)
On Fri, Dec 31, 2021 at 10:43 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Christo Crause via fpc-devel schrieb am > Fr., 31. Dez. 2021, 16:58: > >> On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel < >> fpc-devel@lists.freepascal.org> wrote: >> >>> Hi, >>> on Linux with FPC 3.2.2 the executable size of programs compiled with >>> fpc -On -a (tried with n 2 or 4) >>> is smaller than when the assembler files are deleted (-a omitted). >>> Does it is an expected behaviour? >>> >> >> Using any of the -a options (not sure about -a5?) to output assembly also >> automatically switches to an external linker (for targets with internal >> linkers). Differences in the executables are thus attributable to >> differences in generated output between the internal and external linkers. >> > > The internal ELF linker isn't enabled by default. > > But using -a switches to the external assembler instead of the internal > one and there the same point holds true that slightly different binary > files are generated. > Thanks for the clarification Sven. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assembler file option (-a)
On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > on Linux with FPC 3.2.2 the executable size of programs compiled with > fpc -On -a (tried with n 2 or 4) > is smaller than when the assembler files are deleted (-a omitted). > Does it is an expected behaviour? > Using any of the -a options (not sure about -a5?) to output assembly also automatically switches to an external linker (for targets with internal linkers). Differences in the executables are thus attributable to differences in generated output between the internal and external linkers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Typhon64 or better not?
On Thu, Dec 16, 2021 at 9:03 AM Ralf via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > I have been a calm readers for years and I want to try something Lazarus. > I discovered Typhon64 in the net and wonder if that's someone uses or if > there are more disadvantages than benefits? > > I find interesting that seemingly the cross compilation should work more > simply. Or is that an illusion? > > I would be very happy about some feedback. > Not relevant to this list, perhaps better to ask this in the Lazarus mailing list (laza...@lists.lazarus-ide.org). I assume Typhon64 refers to CodeTyphon? CodeTyphon is a repackaged Lazarus distribution, with some extras. Perhaps read more independent opinions for example: https://www.pascalgamedevelopment.com/showthread.php?22857-CodeTyphon-vs-Lazarus https://stackoverflow.com/questions/16838408/what-is-the-difference-between-lazarus-and-codetyphon ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incorrect debug info for ESP32, linker error?
On Sun, Dec 5, 2021 at 11:45 AM Florian Klämpfl via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
>
> You can try adding tf_dwarf_relative_addresses in i_freertos.pas line 660,
> it appears that xtensa-freertos uses relative addresses.
>
Including this flag results in an unresolved symbol error:
/home/christo/fpc/gitlab-cc/compiler/ppcrossxtensa -Cplx6 -Ur -Tfreertos
-Pxtensa
-XP/home/christo/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-
-Ur -Xs -O2 -n -Fi../inc -Fi../xtensa -FE.
-FU/home/christo/fpc/gitlab-cc/rtl/units/xtensa-freertos -dxtensa -dRELEASE
-Cfhard -g xtensa/esp32.pp
/home/christo/fpc/gitlab-cc/rtl/units/xtensa-freertos/esp32.s: Assembler
messages:
/home/christo/fpc/gitlab-cc/rtl/units/xtensa-freertos/esp32.s:1454: Error:
can't resolve `.debug_info' {.debug_info section} - `.Ldebug_infosection0'
{*UND* section}
esp32.pp(78) Error: Error while assembling exitcode 1
A similar error is also reported for esp8266.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incorrect debug info for ESP32, linker error?
On Sat, Dec 4, 2021 at 5:23 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 04.12.2021 um 14:04 schrieb Christo Crause via fpc-devel: > > When compiling a simple test for esp32 (xtensa-freertos), the incorrect > values for DW_AT_low_PC and DW_AT_high_PC are > > generated. From my inspection of the generated assembler I cannot see > anything wrong, but the values supplied by the > > linker are wrong. Any ideas on how to fix this? > > > > This can be seen below, where there is no overlap between the unit's > low/high PC and main's low/high PC: > > > > <0>: Abbrev Number: 1 (DW_TAG_compile_unit) > > DW_AT_name: test.pp > > <14> DW_AT_producer: Free Pascal 3.3.1 2021/11/27 > > <31> DW_AT_comp_dir: /home/christo/fpc/xtensa/examples/test/ > > <59> DW_AT_language: 9 (ANSI Pascal) > > <5a> DW_AT_identifier_case: 3 (case_insensitive) > > <5b> DW_AT_stmt_list : 0x0 > > <5f> DW_AT_low_pc : 0x400e49e4 > > <63> DW_AT_high_pc : 0x400e49e4 > > <1><67>: Abbrev Number: 2 (DW_TAG_subprogram) > > <68> DW_AT_name: $main > > <6e> DW_AT_prototyped : 1 > > <6f> DW_AT_external: 1 > > <70> DW_AT_low_pc : 0x400d0a70 > > <74> DW_AT_high_pc : 0x400d0ab3 > > > > From the compiler generated assembly it appears that the labels for > these values are correctly placed > > (DEBUGSTART_$P$TEST placed at start of code): > > > > .globl DEBUGSTART_$P$TEST > > DEBUGSTART_$P$TEST: > > # End asmlist al_begin > > # Begin asmlist al_procedures > > > > .section .text.n_main,"ax" > > .balign 4 > > .globl main > > main: > > .globl PASCALMAIN > > PASCALMAIN: > > .Lc2: > > # Start of abi_windowed entry localsize=0 > > > > Below the label is used in the debug info section: > > > > .section .debug_info > > .Ldebug_info0: > > .long .Ledebug_info0-.Lf2 > > .Lf2: > > .short 3 > > .long .Ldebug_abbrev0 > > .byte 4 > > .uleb128 1 > > .ascii "test.pp\000" > > .ascii "Free Pascal 3.3.1 2021/11/27\000" > > .ascii "/home/christo/fpc/xtensa/examples/test/\000" > > .byte 9 > > .byte 3 > > .long .Ldebug_line0 > > .long DEBUGSTART_$P$TEST > > .long DEBUGEND_$P$TEST > > How does the debug info section look like for a gcc generated program? > The debug info for the main file in the project (other file information looks similar): Compilation Unit @ offset 0xf7476: Length: 0x6347 (32-bit) Version: 4 Abbrev Offset: 0xe85d Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer: (indirect string, offset: 0xa4): GNU C99 8.4.0 -mlongcalls -ggdb -Og -std=gnu99 -ffunction-sections -fdata-sections -fstrict-volatile-bitfields DW_AT_language: 12 (ANSI C99) DW_AT_name: (indirect string, offset: 0x14b84): ../main/sd_card_example_main.c DW_AT_comp_dir: (indirect string, offset: 0x689): /home/christo/xtensa/examples/sd_card/build DW_AT_ranges : 0x3148 DW_AT_low_pc : 0x0 DW_AT_stmt_list : 0x59c73 <1>: Abbrev Number: 2 (DW_TAG_base_type) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Incorrect debug info for ESP32, linker error?
When compiling a simple test for esp32 (xtensa-freertos), the incorrect values for DW_AT_low_PC and DW_AT_high_PC are generated. From my inspection of the generated assembler I cannot see anything wrong, but the values supplied by the linker are wrong. Any ideas on how to fix this? This can be seen below, where there is no overlap between the unit's low/high PC and main's low/high PC: <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_name: test.pp <14> DW_AT_producer: Free Pascal 3.3.1 2021/11/27 <31> DW_AT_comp_dir : /home/christo/fpc/xtensa/examples/test/ <59> DW_AT_language: 9 (ANSI Pascal) <5a> DW_AT_identifier_case: 3 (case_insensitive) <5b> DW_AT_stmt_list : 0x0 <5f> DW_AT_low_pc : 0x400e49e4 <63> DW_AT_high_pc : 0x400e49e4 <1><67>: Abbrev Number: 2 (DW_TAG_subprogram) <68> DW_AT_name: $main <6e> DW_AT_prototyped : 1 <6f> DW_AT_external: 1 <70> DW_AT_low_pc : 0x400d0a70 <74> DW_AT_high_pc : 0x400d0ab3 >From the compiler generated assembly it appears that the labels for these values are correctly placed (DEBUGSTART_$P$TEST placed at start of code): .globl DEBUGSTART_$P$TEST DEBUGSTART_$P$TEST: # End asmlist al_begin # Begin asmlist al_procedures .section .text.n_main,"ax" .balign 4 .globl main main: .globl PASCALMAIN PASCALMAIN: .Lc2: # Start of abi_windowed entry localsize=0 Below the label is used in the debug info section: .section .debug_info .Ldebug_info0: .long .Ledebug_info0-.Lf2 .Lf2: .short 3 .long .Ldebug_abbrev0 .byte 4 .uleb128 1 .ascii "test.pp\000" .ascii "Free Pascal 3.3.1 2021/11/27\000" .ascii "/home/christo/fpc/xtensa/examples/test/\000" .byte 9 .byte 3 .long .Ldebug_line0 .long DEBUGSTART_$P$TEST .long DEBUGEND_$P$TEST ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC xtensa-freertos configuration for different esp-idf versions
Recently I updated my esp-idf version to 4.3 and ran into issues with different linker scripts and library requirements. The design of this SDK is still changing even between minor version updates. It seems restrictive to fix the SDK version supported by the compiler when new minor SDK versions are released approximately once every 6 months. I'm wondering if there is some way to pass an SDK version to the compiler, so that the compiler can use the appropriate configuration for that version of SDK? Are there any other targets that have a similar problem, and how was this solved? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
On Fri, Oct 1, 2021 at 11:03 PM Christo Crause wrote: > On Wed, Sep 29, 2021 at 8:42 PM Florian Klämpfl via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Am 29.09.21 um 18:10 schrieb Christo Crause via fpc-devel: >> > There is a long list of AVR commits dating back to 2018. Is someone >> > looking at this, or should I prepare a list? >> >> Not yet, if you can provide one, that would be great! >> > Below a second list of commits for AVR & embedded: 2d9cdab264fc77bc72298006df1621c28a5cb426 28391e04bcf54a5acfddb0f2efe5bcc5614ac4c5 bd96765632bc483c84ed58debfecedcf393ad3b6 429130fa344907371a085ae623791535cb4b101a ae8d2dc69a518eac8950ae09f45061802cda99ee 08c2afb0a42ba236098d73f72e522085cd07bba2 3ab8830b83b461b590340ad8592050a6a587d74f d2a059bd02887993320d4177bc5502b22f83fd56 17c4834a4af3993728c8950b4e41bb77b5a34a93 670c61e7609d02e978a6b0b7f26effdc132a1840 7892e3f7b788c2456a2c8f1e0aef35647d1f 9d91d680fbe877215de88cd898003c7c134d730a 00214406bc108fd4b9f08b28a412cfb2d3442924 7d283f530ecd1ddb80e8b89649f30be7dd56a0ba 36058ca4d441c88b4ddac39de72976cca6560ecd 640fe9c29095d8f2e7f928bf3f775e151173309c 4fe21a8e1a1d5e12ae795ac1f17558d5d55cdf77 e033269deb80e1bf923d26fbee2bd2170bc660cf 5040e31f1164afb3ed60b1cbf98d5f34467ebaf2 04ad607bb43c0508d51c60f88b702b25a339abaa 925979c6e47a9e665d804cb75b5a9b73a534b048 dea63e3d613507fb4e9eb6849a5882c4d62bfa48 a905a074b0c475a8202436547bd02963764cdbcc 297d6e2c60d44a2ded0affad4593f3bff3d5b384 84cfa8d9b0140def94a4caeb8c35fbd6ec395c20 2135b9b724549e4c6b8fc8b5472b098539e1a9bf fd4fb5fa192b149d7f5c33d1820eca00af8430e1 0424c2a658c5bdad38adf30445ad86b8406e42cb fc50edfe31d0c1a6df9461a7ca183253be142199 599b7e80c022ede41935ddee2680ccc63de88ef9 37a3b542e6d2498d0160f29f4b0e84575aa7ef3e b8c707ed7ec518f89df8d3853615a2b556b2fd78 fa543359380db005b6fe48a3cd02df6ba31fa405 eb098a3d116984e3c2fb2ca35e039f060efe8550 3482121831a899c3acf0a8f2d0e2d8e401a2eda5 6d75992674a3f7818195507d9cae1fbc8370c10f 98a748bdd6e3220c299e6cfcbdd64d92e1b335a3 5e1e6c24a48a41549d7293f18fb04805adbc5570 9bfc731bb6722eb6d66391515bcb452fee104f40 9d6ceda532a226c1dfa7a8c110c84fbdc57f1971 aec49340a3f18aeab4204375fa1d6d18c6a59422 89a961f960e8cf2cafc013c31f3a02564bdcd13e 9926eb8dc617931f174afa2106b10bc7467fedf2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
On Sat, Oct 2, 2021 at 10:53 PM Dimitrios Chr. Ioannidis < d.ioanni...@nephelae.eu> wrote: > I think that the CIE dwarf fix should be included also, commit > 1e960a9aeb12ae75877ef9321efbb89f34bbbdce . > Even though that particular commit is simple, it is entangled with commit 65aebd22b0cb4e170964819b3e439f0799ca9138 (eh_frame based exception handling) which isn't part of the eligible commits. It is possible to replace line 370 in fixes_3_2 (tc:=tai_const.create_sym(cielabel);) with tc:=tai_const.create_type_sym(aitconst_32bit,cielabel), unfortunately I don't have a test case to check if this still work as expected. Perhaps Florian can check? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
On Sat, Oct 2, 2021 at 7:42 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > > Am 01.10.2021 um 23:03 schrieb Christo Crause via fpc-devel < > fpc-devel@lists.freepascal.org>: > > Below is a list of commits that kind of merge relatively easily. This > covers most of the relevant AVR patches up to Jan 2020, just before the > avrtiny support was added. There are three commits in this period that > rely on more invasive and widespread changes of other commits, I will list > them separately at the end. > > > Thanks, applied. > > > I needed also > > f92b8d1681c0d1ca2228b3114373085524cd93ff > Indeed, apologies for missing that one. > > Problematic - seems to require commits that affect other targets: > 8fd0a27875abb2636a1388876f590a3a56d83b56 - commit doesn't compile, missing > definition of labelcnt > ae04e5d7f0c2527677b7c4ce6be2c235a4635c82 - doesn't compile, requires > definition of TransferUsedRegs in 94d7a02fae1d06a40fc9313f7e42323f97d577c7 > but that doesn't merge cleanly (conflicts in aoptx86.pas). > 4b4e316af02a968f27147123b189b04a9931ba79 - requires commit or fix that > renames FPC_in_cpu_first to in_cpu_first > > > If they do not fix really important things, then I would leave them out. > There are a couple of refactoring commits in the aopt units that seem like general improvements (e.g. 94d7a02fae1d06a40fc9313f7e42323f97d577c7) which haven't been picked yet. Will these be merged at some point, maybe 3.4? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
On Wed, Sep 29, 2021 at 8:42 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 29.09.21 um 18:10 schrieb Christo Crause via fpc-devel: > > There is a long list of AVR commits dating back to 2018. Is someone > > looking at this, or should I prepare a list? > > Not yet, if you can provide one, that would be great! > Below is a list of commits that kind of merge relatively easily. This covers most of the relevant AVR patches up to Jan 2020, just before the avrtiny support was added. There are three commits in this period that rely on more invasive and widespread changes of other commits, I will list them separately at the end. 42e54c1ad5262f0954375c9e40fa4cc8cc32ab7c 917de001d6af01c4d3f11a6ddfe59935ee859a8f 8fceba449334735be058a1db4dbf1d8c5f999046 12879adc2f370c6bbdaa8dd2e0b80a0174ddb82b 3ad450c6364e471810e008a2bf13b1e48b4d849b c867d2b7f64b4fe56c923924c40199447512dc48 009c87156a1ca1f2eb6b08f7bc01e0e7816eb13c 2f501be2a0a17091460c8307862671cb9dbff45b 5bdc635f50c284217c336a407da774c6850a7f9e dee01978907bf4ae544fe53c95a81cea34f1ce4d aa4961d06e12c43a802ee25305d8805cf1ff1414 ee7bc1d5165d96fce1437d625b29649b0c95b322 0d97dc7965dd95f7b44692d57851aca0db2894dd 48a7c0989a8858737ecc18fc62f237753d1d05c9 030cf78ac58eadfe491877676d8a5a51844514c5 ff3372567f16be75ed1762f3fd5b302faa5e12d6 4b93eb64b314ef1c127156b17da59bbba14bc13d 893507a5d6b0fbd28568154fbf63d6053fefbc1a 91016c97a43192836780f6bd5b1c0da01f1d4b6b f72342ed0e7e2c4e268de982a64222dcdc3d75af 1b698d319fd2f30ea9314b18063f9f64c1cf23c5 9e5cbce6be0c5658610ab93e1f193ef7cc289f7f 05c4f45596c7605a5c1801ae86efd86a1a006d18 4e93a9a6c7ad4eac2ec416f724013dd4a0860cf2 dd2d1bf68b5c85c66a1d59b2f1d2319cb3b726af 5fc12500f277327255e011decd672285b71892c7 3b1903b43056f112b340c878699dbf7f80b16ded f61207f1cc24fd547353895c8b83154527b0be64 e8a48be3bcc50859231ef4550e43f9f677164155 701848889e58254c7925415dee7212ff655b6264 fabe4cc0676679fde2b8d888dd81b902eed4b3be 6f434b6751b2fb4f459e5f004086c6ede5436309 96a4cda03b66fc568b5e6bc1421e9465b772b594 aaa6ae5770d07ee28be4e17ba331f45d940bb6bd 26eae3672ba6b5981d7a473094d7d22815b359b0 f629fa1bb9760e2dc2b0ee9761b0c52bf76b4fa7 Problematic - seems to require commits that affect other targets: 8fd0a27875abb2636a1388876f590a3a56d83b56 - commit doesn't compile, missing definition of labelcnt ae04e5d7f0c2527677b7c4ce6be2c235a4635c82 - doesn't compile, requires definition of TransferUsedRegs in 94d7a02fae1d06a40fc9313f7e42323f97d577c7 but that doesn't merge cleanly (conflicts in aoptx86.pas). 4b4e316af02a968f27147123b189b04a9931ba79 - requires commit or fix that renames FPC_in_cpu_first to in_cpu_first ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
On Sun, Sep 26, 2021 at 10:42 AM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > A log of not yet considered commits can be found at > https://gitlab.com/freepascal.org/fpc/merging/-/blob/main/eligible.log > There is a long list of AVR commits dating back to 2018. Is someone looking at this, or should I prepare a list? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Using -a or -s option forces change to external assembler
On Linux 64 bit the compiler defaults to using the internal assembler. When adding the -a command line option an external assembler is called. This is unexpected based on the description of the -a option. Specifying -Aelf (to force using the internal assembler) is also ignored when used with -a, without a message. Also when using the -s option the internal assembler is disabled, again somewhat unexpectedly in my opinion. Is this behaviour documented somewhere else? Since it is unexpected (at least from my understanding of the documentation), can this behaviour be added to the command line help output? Would it make sense to implement an alternative interpretation, where the internal assembler is used if specified/default with just an output writer for the -a case? In the case of -s there would be no assembler output, so the user can then only check and tweak the linking step. Best regards, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Moving to gitlab.
A document discussing the SVN support of github, just for reference: https://docs.github.com/en/github/importing-your-projects-to-github/working-with-subversion-on-github/support-for-subversion-clients On Thu, 22 Jul 2021, 15:56 J. Gareth Moreton via fpc-devel, < fpc-devel@lists.freepascal.org> wrote: > For those who connect to the SVN repository through a command-line > terminal to update the trunk, can we have instructions on how to connect to > the new GitHub repository this way? The instructions aren't yet on > https://www.freepascal.org/develop.html, presumably because it's not yet > live or at least ready. > > Gareth aka. Kit > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Sun, Jan 24, 2021 at 10:13 PM Christo Crause wrote: > > On Tue, Jan 19, 2021 at 8:52 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> >> It isn't that hard. You essentially need to make sure that the necessary >> information is written in tpointerdef.ppuwrite and read again in >> tpointerdef.ppuload. You also need to increase the PPULongVersion in unit >> ppu and adjust the code in the ppudump utility. >> > > Thank you Sven and Jonas, your hints helped me a lot. For AVR, pointer > types can now refer to sections and the compiler can generate appropriate > access for pointer parameter types. > > My next challenge is to extend error checking so that call parameters are > checked for section incompatibility. > A quick update: By adding section information to type definitions (tdef) and type symbols it is possible to propagate the necessary information via parameters. Now it is possible to write overloaded procedures that handle section information correctly. type Byte_e = type Byte; section '.eeprom'; procedure writeTest(var a: byte); overload; begin a := 123; end; procedure writeTest(var a: byte_e); overload; begin a := 234; end; Other functionality and error checking is demonstrated in the various test cases here: https://github.com/ccrause/freepascal/tree/sectionsupport-rtl/tests/test/avr Comments and suggestions are welcome. Next development will focus more on complicated types such as strings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Core] Dangerous download on bug report
On Wed, Feb 24, 2021 at 1:50 PM Luca Olivetti via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I don't see any comment made on that date. I see one made at 2021-02-07 > 22:07 and the next one is at 2021-02-23 21:57 I also see the same gap from the 7th to the 23rd. Perhaps the message was marked as private and one needs admin or developer status to view it? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR systeminfo defaults to dwarf 3
On Wed, Feb 10, 2021 at 3:16 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > Στις 10/2/2021 2:25 μ.μ., ο/η Christo Crause έγραψε: > > On Wed, Feb 10, 2021 at 12:47 PM Dimitrios Chr. Ioannidis via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Hi, >> >>I read at compiler/systems/i_embed.pas the AVR systeminfo, is the >> only one that, has as default "dbg : dbg_dwarf3". The other embed >> systems that uses dwarf ( ARM, MIPSEL, i8086, m68k, RISCV32/64, XTENSA, >> Z80 ), all have as default "dbg : dbg_dwarf2". >> >>The AVR has problems with dbg_dwarf2 ? If not, could you please >> change the AVR systeminfo to dwarf2 also for consistency ? >> > > That was a fix for compiling controller units with lots of symbols, refer > to this discussion thread: > https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg35416.html > Dwarf2 is fine in general, unless the address (I think address in dwarf > debug section, the details are a bit hazy in my memory) of symbols exceed > 65535. Dwarf3 offers a larger data type for this scenario. > > I'm using ppcrossavr with systeminfo default "dbg : dbg_dwarf2" with no > problems. If I remember correctly, IMHO, fixing the issue 33914 ( > https://bugs.freepascal.org/view.php?id=33914 ) had the collateral effect > to fixing also the above. > > For test, I just debugged a physical atmega32u2 mcu with Lazarus with no > problems at all. Also for test, I builded an avr35 subarch ppcrossavr and > also debugged a physical atmega32u2 mcu with no problems. > You are probably right, I never checked if the pointer change of #33914 also fixed the original issue in the mailing list so the default dwarf version for AVR could be changed back to 2. But then Florian does have a point, why not make the default for all targets dwarf 3? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR systeminfo defaults to dwarf 3
On Wed, Feb 10, 2021 at 12:47 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > >I read at compiler/systems/i_embed.pas the AVR systeminfo, is the > only one that, has as default "dbg : dbg_dwarf3". The other embed > systems that uses dwarf ( ARM, MIPSEL, i8086, m68k, RISCV32/64, XTENSA, > Z80 ), all have as default "dbg : dbg_dwarf2". > >The AVR has problems with dbg_dwarf2 ? If not, could you please > change the AVR systeminfo to dwarf2 also for consistency ? > That was a fix for compiling controller units with lots of symbols, refer to this discussion thread: https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg35416.html Dwarf2 is fine in general, unless the address (I think address in dwarf debug section, the details are a bit hazy in my memory) of symbols exceed 65535. Dwarf3 offers a larger data type for this scenario. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] dwarf 2 warning CIE
On Tue, Feb 2, 2021 at 12:28 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > Reading dwarf information with avr-embedded-objdump.exe --dwarf returns > : "avr-embedded-objdump.exe: Warning: Invalid CIE pointer 0x00c8 in > FDE at 0x14" > I get the same warning on Linux using avr-objdump (GNU objdump (GNU Binutils) 2.26.20160125), your test code and all of the dwarf debug options in the compiler. Not sure if this is really a problem when debugging with gdb, I've managed to debug across units before. Do you have a reproducible problematic debug situation that can be tested? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Sun, Jan 24, 2021 at 10:13 PM Christo Crause wrote: > My next challenge is to extend error checking so that call parameters are > checked for section incompatibility. > Is there a way to define and run specific new tests only (say in a tests/testfolder/avr), in the compiler test folder? At the moment I've butchered the MakeFile and commented out the different test folders I'm not focussing on at the moment. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Tue, Jan 19, 2021 at 8:52 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > It isn't that hard. You essentially need to make sure that the necessary > information is written in tpointerdef.ppuwrite and read again in > tpointerdef.ppuload. You also need to increase the PPULongVersion in unit > ppu and adjust the code in the ppudump utility. > Thank you Sven and Jonas, your hints helped me a lot. For AVR, pointer types can now refer to sections and the compiler can generate appropriate access for pointer parameter types. My next challenge is to extend error checking so that call parameters are checked for section incompatibility. ___ 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
On Sat, Jan 23, 2021 at 12:07 AM Florian Klämpfl via fpc-devel < 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
Re: [fpc-devel] Proposal for implementing named address space support
On Sun, Jan 17, 2021 at 3:51 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 08.01.21 um 22:00 schrieb Christo Crause via fpc-devel: > > On Sun, Oct 4, 2020 at 1:49 PM Christo Crause > <mailto:christo.cra...@gmail.com>> wrote: > > var > >w: word = $BEEF; section '.eeprom'; > >b: byte; > > > > procedure doSomething(constref tmp: word); > > begin > >b := hi(tmp); > > end; > > > > begin > >doSomething(w); > > end. > > > > At the moment there doesn't appear to be a way to do this without > > changing or adding something to the compiler. One idea could be to > > define new types identifying types in a specific address space, such as > > Teepromword. In this case the above example could be written as: > > var > >w: Teepromword = $BEEF; > >b: byte; > > > > procedure doSomething(constref tmp: word); overload; > > begin > >b := hi(tmp); > > end; > > > > procedure doSomething(constref tmp: Teepromword); overload; > > begin > >b := hi(tmp); > > end; > > > > begin > >doSomething(w); > > end. > > > > This way the compiler knows how to generate appropriate access based on > > the parameter type. It however leads to lots of code duplication. Which > > got me thinking about generics - could this be handled internally in the > > compiler via generics? It isn't clear to me how to tackle these issues > > so any advice would be appreciated. > > I would simply not allow to use such references as independent pointers. > This causes too much bloat. They can be used in assignments and > expressions and that's it. > I have given up on that idea. I'm now busy working on Jonas's suggestion of section specific pointers (example: https://github.com/ccrause/freepascal/wiki/Better-support-for-address-spaces-in-FPC#section-pointer-example ). At the moment it introduces no runtime overhead (other than the required access instructions of course), but to make it work across units is problematic. I suspect an extra field is required to store the section information associated with a pointer type (at least the way I've implemented it) in a ppu. If unit A defining such a pointer and a procedure using it is as parameter is called from unit B, it works if both units are compiled together. If unit A is already compiled and unit B is recompiled (symbols loaded from ppu) it doesn't carry the section information across and the compiler cannot determine which overloaded procedure to call. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Sat, Jan 9, 2021 at 3:52 PM Jonas Maebe via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > On 08/01/2021 22:00, Christo Crause via fpc-devel wrote: > > However I see problems with propagating section information through > > reference type parameters. I'm not sure how to propagate the section > > information of the variable "w" through the parameter > > Can't you use something like the far pointers used on the 8086 target? ( > (a regular pointer only contains an offset, a far pointer contains both > a segment and an offset) If so, the main downside is that it would > increase the size of all reference parameters to include room for the > section part of the pointer, unless you add a directive to disable that > (or couple it to the existing farpointers directive). > Thanks for the idea Jonas. This could be a solution as is, but as you mentioned it comes with a parameter size penalty. Using a generic offset for the section (unknown at compile time on the callee side) would require runtime handing of the different access methods to the different address spaces, increasing code size. These two concerns are deal breakers for microcontrollers (at least in my opinion). Could your idea not be simplified by allowing the use of the section directive when defining a pointer? type Peeprom = pointer; section '.eeprom'; This way when a parameter is defined as e.g. type Peeprom the compiler knows what access code should be generated for the specified section. It would also help with compile time error checking where assigning a regular pointer to a section pointer should not be allowed (unless the user applies a type cast). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Sun, Oct 4, 2020 at 1:49 PM Christo Crause wrote: > FPC can use the section modifier to specify which address space should be > used for data. > I've made some progress in certain areas (basically static variables), the following type of AVR code example works: var w: word = $BEEF; section '.eeprom'; b: byte; begin b := hi(w); end. However I see problems with propagating section information through reference type parameters. I'm not sure how to propagate the section information of the variable "w" through the parameter into the procedure of the following example: var w: word = $BEEF; section '.eeprom'; b: byte; procedure doSomething(constref tmp: word); begin b := hi(tmp); end; begin doSomething(w); end. At the moment there doesn't appear to be a way to do this without changing or adding something to the compiler. One idea could be to define new types identifying types in a specific address space, such as Teepromword. In this case the above example could be written as: var w: Teepromword = $BEEF; b: byte; procedure doSomething(constref tmp: word); overload; begin b := hi(tmp); end; procedure doSomething(constref tmp: Teepromword); overload; begin b := hi(tmp); end; begin doSomething(w); end. This way the compiler knows how to generate appropriate access based on the parameter type. It however leads to lots of code duplication. Which got me thinking about generics - could this be handled internally in the compiler via generics? It isn't clear to me how to tackle these issues so any advice would be appreciated. Best regards, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Fri, Jan 1, 2021 at 7:01 PM Christo Crause wrote: > > On Fri, Jan 1, 2021 at 3:59 PM Florian Klämpfl via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> - you need to get the value of EECR: I would try with >> symtable.searchsym_in_module >> > Thanks for this hint. Settled on searchsym to find the symbol, I managed to make some further progress from there. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Fri, Jan 1, 2021 at 3:59 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > - you need to get the value of EECR: I would try with > symtable.searchsym_in_module > - for ideas how a load node could generate code for a variable access as > above, I would take the various generate_threadvar_access methods as > example. > Thanks for the hints Florian. I'll look into this. Is your current code somewhere available? > It is now on Github: https://github.com/ccrause/freepascal/tree/sectionsupport ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
On Thu, Dec 31, 2020 at 9:42 PM Jonas Maebe via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > On 31/12/2020 20:32, Christo Crause via fpc-devel wrote: > > > For example I do not know how to generate the equivalent to the > > following user assembler code: > > lds r0, EECR > > where EECR is defined as follows in a different unit: > > var EECR: byte absolute $1F; > > > > The following line illustrates what I'm attempting to do: > > list.concat(taicpu.op_reg_ref(A_LDS,tmpreg,tmpref)); > > where tempref should reference the EECR symbol in another unit. > > > > How do I build such a reference in the code generator so that the > > reference can resolve to the appropriate address? > > While possible, the code generator is the wrong abstraction level for > this. Can't you generate a load node for that variable instead? What > triggers this code generation? > Jonas, Thank you for your help. I'm trying to implement compiler support for different address spaces (flash and eeprom memory at the moment), mostly relevant to embedded and freertos type targets. My current approach is to check for specific section names of references in the code generator and then generate the appropriate access code in tavr.g_concatcopy tavr.a_load_ref_reg and so forth. Example code I want to support: program store_restarts; var numrestarts: byte; section '.eeprom'; begin numrestarts := 42; end; Reading from section .progmem closely follows the semantics of accessing general RAM so it was relatively easy to extend the existing code generator for that. EEPROM access requires more code (not a problem) but also controller specific register addresses (here is my problem, the information sits in a different unit). I haven't thought of modifying or creating a the load node since I'm much more familiar with the code generator side of the compiler (but still no expert...). Any further hints or examples in the compiler I can study to tackle this via a load node would be appreciated. Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal for implementing named address space support
I'm busy adding EEPROM access to the code generator for AVR. Although the general code required is relatively straight forward, the problem I ran into is that the EEPROM access registers are not at the same addresses for the different controllers. The register names and addresses are included in the respective controller units, so the addresses are available in the automatically loaded controller unit at compile time. For example I do not know how to generate the equivalent to the following user assembler code: lds r0, EECR where EECR is defined as follows in a different unit: var EECR: byte absolute $1F; The following line illustrates what I'm attempting to do: list.concat(taicpu.op_reg_ref(A_LDS,tmpreg,tmpref)); where tempref should reference the EECR symbol in another unit. How do I build such a reference in the code generator so that the reference can resolve to the appropriate address? Regards, Christo On Sun, Oct 4, 2020 at 1:49 PM Christo Crause wrote: > The AVR architecture uses different address spaces with potentially > different access methods [1]. Currently constant data (messages, bitmaps > etc.) are stored in flash and copied to RAM by the start-up code. Data > access makes use of the LD* instructions (and ST* if the data is > writeable). Accessing e.g. read-only data directly from flash saves RAM > space - this can be done byt informing the linker to locate the data in the > progmem section. While one can use the section modifier to inform the > linker to place data in specific address spaces it still require user > supplied access code. This leads to code and maintenance duplication for > the user to cater for different memory spaces, with associated code bloat. > > The xtensa architecture has several address reagions that can be used for > different purposes [2]. One example would be to place time critical > interrupt code in the IRAM address space. The DRAM space can also be used > to store constant data which can be accessed from an interrupt routine. > Several other address spaces are available for specific use cases [3]. > > FPC can use the section modifier to specify which address space should be > used for data. It is however very limited in that the code generator is > not aware of the potentially different address spaces that can be > specified, hence it is up to the user to provide the correct access code > (for AVR). The section modifier also takes a user supplied string, which > currently isn't checked for sensible or allowed values. I want to propose > a unified mechanism for specifying both data and instruction address spaces > using the same syntax for functions/procedures and variables, together with > implementing the necessary access functionality as required (mainly AVR) > for the compiler to generate the appropriate code without further user > involvement. > > The first proposal is to extend the section modifier to accept predefined > (target specific) keywords (flash, eeprom, iram, dram, rtc_noinit and > others), e.g.: > // AVR const data in flash > const > smileyGlyph: array[0..6] of byte = (19, 35, 64, 92, 64, 35, 19); section > flash; // keep data in flash, read using spm (or LD* for newer AVRs) > > // AVR Read/write access to data stored in EEPROM > var > restartCount: byte; section eeprom; // If one needs a fixed location, > perhaps use in combination with absolute? > > // Xtensa interrupt handler user code > procedure encoderPulse; section iram; > > // Xtensa code that executes after wakeup from deep sleep > procedure afterDeepSleep; section rtc_iram; > > // Xtensa variable that retains value after deep sleep: > var > oldState: uint32; section rtc_slow_data; > > The alternative is to skip the section modifier and simply use the various > keywords (flash, iram etc.) as modifiers. Not sure if there is any > advantage of this compared to the first proposal. > > Critique, improvements and other use cases to consider would be > appreciated. > > [1] > https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR-Named-Address-Spaces > [2] > https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/general-notes.html#memory-layout > [3] > https://github.com/espressif/esp-idf/blob/7b7c641076ef4c5dff7b994170d445bbb46f81ab/components/xtensa/include/esp_attr.h#L21 > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Proposal for implementing named address space support
The AVR architecture uses different address spaces with potentially different access methods [1]. Currently constant data (messages, bitmaps etc.) are stored in flash and copied to RAM by the start-up code. Data access makes use of the LD* instructions (and ST* if the data is writeable). Accessing e.g. read-only data directly from flash saves RAM space - this can be done byt informing the linker to locate the data in the progmem section. While one can use the section modifier to inform the linker to place data in specific address spaces it still require user supplied access code. This leads to code and maintenance duplication for the user to cater for different memory spaces, with associated code bloat. The xtensa architecture has several address reagions that can be used for different purposes [2]. One example would be to place time critical interrupt code in the IRAM address space. The DRAM space can also be used to store constant data which can be accessed from an interrupt routine. Several other address spaces are available for specific use cases [3]. FPC can use the section modifier to specify which address space should be used for data. It is however very limited in that the code generator is not aware of the potentially different address spaces that can be specified, hence it is up to the user to provide the correct access code (for AVR). The section modifier also takes a user supplied string, which currently isn't checked for sensible or allowed values. I want to propose a unified mechanism for specifying both data and instruction address spaces using the same syntax for functions/procedures and variables, together with implementing the necessary access functionality as required (mainly AVR) for the compiler to generate the appropriate code without further user involvement. The first proposal is to extend the section modifier to accept predefined (target specific) keywords (flash, eeprom, iram, dram, rtc_noinit and others), e.g.: // AVR const data in flash const smileyGlyph: array[0..6] of byte = (19, 35, 64, 92, 64, 35, 19); section flash; // keep data in flash, read using spm (or LD* for newer AVRs) // AVR Read/write access to data stored in EEPROM var restartCount: byte; section eeprom; // If one needs a fixed location, perhaps use in combination with absolute? // Xtensa interrupt handler user code procedure encoderPulse; section iram; // Xtensa code that executes after wakeup from deep sleep procedure afterDeepSleep; section rtc_iram; // Xtensa variable that retains value after deep sleep: var oldState: uint32; section rtc_slow_data; The alternative is to skip the section modifier and simply use the various keywords (flash, iram etc.) as modifiers. Not sure if there is any advantage of this compared to the first proposal. Critique, improvements and other use cases to consider would be appreciated. [1] https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html#AVR-Named-Address-Spaces [2] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/general-notes.html#memory-layout [3] https://github.com/espressif/esp-idf/blob/7b7c641076ef4c5dff7b994170d445bbb46f81ab/components/xtensa/include/esp_attr.h#L21 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xtensa compiler error when building RTL
On Sun, Aug 30, 2020 at 10:55 PM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > Should be fixed now. > Confirmed, trunk works again for xtensa. Thanks Florian! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xtensa compiler error when building RTL
On Sun, Aug 30, 2020 at 11:37 AM Florian Klämpfl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 30.08.20 um 10:40 schrieb Christo Crause via fpc-devel: > > Since the bug tracker is offline I want to highlight this problem, > > before it slips my mind: > > > > Updating trunk revision this morning results in a failure for > > freertos-xtensa RTL (the cross compiler itself successfully > bootstrapped): > > Yes, I know it. I am currently reworking the windowed abi calling > convention handling in the compiler. > Thank you Florian. Since you are busy working on this I will not log an issue. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Xtensa compiler error when building RTL
Since the bug tracker is offline I want to highlight this problem, before it slips my mind: Updating trunk revision this morning results in a failure for freertos-xtensa RTL (the cross compiler itself successfully bootstrapped): make OS_TARGET=freertos CPU_TARGET=xtensa FPC=~/fpc/3.3.1/compiler/ppcrossxtensa BINUTILSPREFIX=xtensa-esp32-elf- SUBARCH=lx6 CROSSOPT="-Cfhard" rtl make -C ../rtl 'OPT=' all make[1]: Entering directory '/home/christo/fpc/3.3.1/rtl' make -C freertos all make[2]: Entering directory '/home/christo/fpc/3.3.1/rtl/freertos' make[2]: ../compiler/ppc: Command not found /home/christo/fpc/3.3.1/compiler/ppcrossxtensa -Cplx6 -Tfreertos -Pxtensa -XPxtensa-esp32-elf- -Xr -Fi../inc -Fi../xtensa -FE. -FU../../rtl/units/xtensa-freertos -Fl/home/christo/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.2.0 -dxtensa -Cfhard -Us -Sg system.pp @system.cfg softfpu.pp(609,1) Fatal: Internal error 2020082801 This error appeared after commit 46732. Note that subarch lx106 RTL builds successfully. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Planning to experiment with FPC extentions
On Wed, 26 Aug 2020, 03:02 Boian Mitov via fpc-devel, < fpc-devel@lists.freepascal.org> wrote: > I have been planning for long time to try to add support for advanced RTTI > to FPC, but never had the chance to work on it. > I don’t even know how to start. Is there any information on how to setup > for recompiling the compiler sources and even where the sources and the > project files for the compiler are? > Can someone help me setup so I can start to study the code and see how I > can start working on it? > This page has a summary of where one can locate the source: https://www.freepascal.org/develop.html The official repository uses svn. I find it a bit easier to work with git, this is a good place to fork from if you prefer git: https://github.com/graemeg/freepascal As Ryan mentioned, start with one of the Lazarus projects in the compiler folder, this is a quick why to modify, compile and test. Once you are satisfied the next step is to build the whole tree (compiler, rtl, packages, utilities) using make. If this works, run the test suite in the tests folder. Good luck! > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler development guides
On Tue, Aug 18, 2020 at 2:52 PM Dmitriy Pomerantsev via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hello. Are there any guides for those who want to try adding something to > the compiler? For example, I would like to try making a new backend. Is > there some example template, etc? Or just other backend code examples? > There are a couple of wiki pages with some information, see e.g. https://wiki.lazarus.freepascal.org/Porting_Free_Pascal and the links at the bottom of the page. It is unfortunately not very detailed and outdated, hence the advice to rather look at existing backend code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with thread local storage for xtensa-freertos
It was an alignment error. I thought the alignment check was active in SysInitThreadvar but a) it was commented out, and b) the ifdef check was incorrect anyway. On Fri, Jul 3, 2020 at 9:47 AM Christo Crause wrote: > Busy working on threading and TLS, started with a stand-alone unit along > the lines of cthreads and using OS memory allocation for storing the TLS > blocks. After initializing (calling SysInitMultithreading) a block of > memory is allocated and threadvars copied. However there appears to be a > two byte offset in the location of the threadvars after relocating them, > see test and output below. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Problem with thread local storage for xtensa-freertos
Busy working on threading and TLS, started with a stand-alone unit along
the lines of cthreads and using OS memory allocation for storing the TLS
blocks. After initializing (calling SysInitMultithreading) a block of
memory is allocated and threadvars copied. However there appears to be a
two byte offset in the location of the threadvars after relocating them,
see test and output below.
program testTLS;
uses fthreads;
threadvar
x, y, z: uint32;
begin
x := $11ABCDEF;
y := $99887766;
z := $55443322;
writeln('Initial x location: ', HexStr(@x), '. Value = ',
HexStr(pointer(x)));
writeln('Initial y location: ', HexStr(@y), '. Value = ',
HexStr(pointer(y)));
writeln('Initial z location: ', HexStr(@z), '. Value = ',
HexStr(pointer(z)));
writeln('Initializing threads...');
fthreads.SysInitMultithreading;
writeln('Current x location: ', HexStr(@x), '. Value = ',
HexStr(pointer(x)));
writeln('Current y location: ', HexStr(@y), '. Value = ',
HexStr(pointer(y)));
writeln('Current z location: ', HexStr(@z), '. Value = ',
HexStr(pointer(z)));
repeat until false;
end.
Output:
Initial x location: 3FFB268C. Value = 11ABCDEF
Initial y location: 3FFB2694. Value = 99887766
Initial z location: 3FFB269C. Value = 55443322
Initializing threads...
Current x location: 3FFB7E12. Value = CDEF
Current y location: 3FFB7E16. Value = 776611AB
Current z location: 3FFB7E1A. Value = 33229988
This is a little endian system so the output can be explained by shifting
the pointer references back (before the actual location) by two bytes.
Somewhere between how FPC presents the pointers to the thread vars, how the
RTL access the pointers and how the new implementation allocates and
presents the storage pointer there appears to be a mismatch. One thing I
would like to investigate is how the compiler packs the thread vars and how
the relocated data is interpreted by the RTL.
Any hints on what to look for?
Attached the fthreads unit for reference.
Best regards,
Christo
fthreads.pas
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and Z80
On Tue, 23 Jun 2020, 17:18 , wrote: > Hi Christo, > > I'm using exactly trunk, as written in article, but for MSXDOS target > isn't working as seen in logs I sent before. But when I build FPC for > spectrum as target, everything works fine (100% compiling successful). > OK, I was confused by the mention of 3.2. :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and Z80
On Tue, Jun 23, 2020 at 3:56 PM wrote: > Hi FPC team. > > I'm trying to compile a FPC 3.2 with support to Z80/MSXDOS, for linux and > almost everything seems to be compiling fine, because the compiler was > generated but RTL was not. > > AFAIK Z80 support is not included in the stable release, so you have to use trunk for Z80. This is also mentioned in the Overview paragraph of the wiki page you refer to below. > I'm using the same build script of zxspectrum (I just changed OS_VERSION > to MSXDOS) that can be reached here https://wiki.freepascal.org/Z80 > (follow the Building paragraph). > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
On Tue, Jun 9, 2020 at 3:19 PM wrote: > On 6/9/20 2:55 AM, Christo Crause via fpc-devel wrote: > > for c := 'A' to 'Z" do write(c); > > oops! i failed to note that the above is character by character whereas > what i > spoke of in my previous post is line by line :/ > Indeed, the first modification attempt will result in a low level flush per character for this case. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
On Tue, Jun 9, 2020 at 10:55 AM Tomas Hajny wrote:
> Note that there is an (intended) difference between output to console
> and output to files (Do_IsDevice provides this differentiation in
> standard RTL). Output to console is supposed to be flushed after every
> Write(Ln) statement, because it should provide immediate feedback to the
> user.
This already works well enough, the normal use case doesn't require a low
level flush.
> [...]
>
> Finally, note that TP-compatible part of the standard RTL does _not_
> call the ("low-level") flush call of the underlying operating system.
> Such calls exist in API for most platforms (DOS: int 21h, AH=68h; OS/2:
> DosResetBuffer; Unix: (fp)fsync; WinXX: FlushFileBuffers), but they are
> not used within our RTL implementation as far as I know (flushing is
> always performed automatically when closing a file, but the operating
> systems take care of that).
>
Indeed, the functionality implemented in the RTL is about managing the RTL
buffers and leaving the downstream work in the hands of the OS (or whatever
custom function is hooked to InOutFunc). I cannot see a simple way to
re-use one of the fields in TextRec to provide what would amount to new
functionality, this leaves the option of adding another field to TextRec
for a low level flush. This is however not moving in the appropriate
direction, since this would lead to higher memory consumption on lower end
targets. Perhaps a separate platform specific low level flush is the best
compromise for the few use cases requiring low level control.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
On Tue, Jun 9, 2020 at 12:03 AM Michael Van Canneyt wrote: > Could you please submit a patch with this modification to the bugtracker ? > > We don't as a rule follow up on such things in github. > I will of course submit a patch once I'm satisfied it is good enough. My concern with the current patch is that a low level flush is called after every write statement, so a simple loop like the following: for c := 'A' to 'Z" do write(c); will incur the burden of a low level flush after each iteration. In normal use the low level flush call is not needed and causes unnecessary blocks. This is what Tomas mentioned, so I'm looking for a different implementation that can fit in with the rest of the use cases in the RTL. It would make more sense to me if there was a distinct difference in use case between InOutFunc and FlushFunc (for fmoutput case), to my naive view it seems as if they are mostly used interchangeably and in many cases even share the same implementation function. This makes sense for the traditional targets (Windows, Linux etc.), but for lower level targets a distinction between the internal RTL buffer and the external OS/hardware buffer is useful. For a low level target I would think an InOutfunc that flushes the internal buffer to the OS/hardware and a FlushFunc that ensures the internal buffer is empty and then blocks until the OS/hardware has completed transmission would make sense. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
Thank you Michael and Jonas for your help and suggestions. I think I ended up merging your suggestions, which does work for my corner case. If anyone is interested this change can be viewed here: https://github.com/ccrause/freepascal/commit/b28ab72ed07f11677493d5d0e37ee451d2313323 I must admit that I was thoroughly confused by the apparent lack of semantic difference in use between InOutFunc and FlushFunc of TextRec structure. Best wishes, Christo On Mon, Jun 8, 2020 at 9:58 PM Jonas Maebe wrote: > On 07/06/2020 19:16, Christo Crause via fpc-devel wrote: > > I want to change the _haltproc for freertos ESP controllers to use > > normal write/writeln functionality to send information to standard > > output. On these targets the output is typically buffered serial > > provided by the OS. Text output written just prior to setting the cpu > > to sleep doesn't get sent, hence a flush is needed to complete data > > transmission before putting the cpu to sleep. Looking at > > consoleio.OpenIO there doesn't seem to be a convenient way to provide a > > flush helper function. Also the RTL Flush procedure calls InOutFunc and > > not FlushFunc. > > > > What is the proper way to hook a flush helper function into the existing > > RTL infrastructure? > > The flushfunc is called from fpc_write_end and fpc_writeln_end. Those > helpers are automatically called after all of the individual write > operations from a write(ln) statement have been processed. So if you > implement/assign flushfunc and make it call your OS flush function, it > should work fine. > > > Jonas > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
Michael, it is entirely possible that I am misunderstanding your suggestion, I probably don't grasp the complexities of the RTL texmode IO system and also not explaining my intention clearly, for this I apologise. Take for example the esp32 unit provided by Florian, here the link between the underlying OS output and the RTL is configured by calling OpenIO and providing readchar and writechar functions which in turn calls getchar and putchar ( https://github.com/ccrause/freepascal/blob/76911c528251b48e18c348de1758c098ee9fb763/rtl/freertos/xtensa/esp32.pp#L106). In this unit Florian uses a custom printpchar procedure which pushes characters to the OS and at the end directly calls the OS fflush function. This ensures that the haltproc message gets transmitted before the cpu goes to sleep. I'm trying to change the controller unit to use standard RTL write functionality, since this gets configured during unit initialization anyway. My attempt at "Pascalizing" Florian's version ( https://github.com/ccrause/freepascal/blob/76911c528251b48e18c348de1758c098ee9fb763/rtl/freertos/xtensa/esp8266.pp#L59) calls the normal write functionality and works, except for the last string before esp_deep_sleep which doesn't reach the remote terminal. At the moment I fix this by directly calling the OS fflush function. The only configuration option exposed via consoleio is OpenIO, which doesn't have a parameter for a low level flush function. I could create an overloaded OpenIO function with an extra parameter for a flush function pointer, and call this, if assigned, at the end of Console_Write. Is this kind of the lower level detail behind your suggestion Michael? Best regards, Christo On Mon, Jun 8, 2020 at 3:27 PM Michael Van Canneyt wrote: > > > On Mon, 8 Jun 2020, Christo Crause via fpc-devel wrote: > > > On Mon, Jun 8, 2020 at 12:15 PM Tomas Hajny wrote: > > > >> On 2020-06-08 11:39, Michael Van Canneyt wrote: > >>> On Mon, 8 Jun 2020, Christo Crause via fpc-devel wrote: > >> . > >> . > >>>> Thanks for your response Michael. Using InOutFunc to also flush the > >>>> output > >>>> buffer will work, but that seems inefficient, since the flush needs to > >>>> wait > >>>> until the transmit buffer is empty (at slow UART speeds this could > >>>> potentially take several ms to complete). Is there a specific reason > >>>> why > >>>> the RTL Flush procedure does not call the FlushFunc method? > >>> > >>> I checked; That code is so old, no idea. > >>> > >>> From what I can see the flush code could be changed to > >>> > >>> if Assigned((TextRec(t).FlushFunc) then > >>> FileFunc(TextRec(t).FlushFunc)(TextRec(t)) > >>> else > >>> FileFunc(TextRec(t).InOutFunc)(TextRec(t)); > >>> > >>> But keep in mind that the InoutFunc() is only called when actually > >>> writing > >>> data, meaning: when the internal text buffer is full or on a terminal > >>> with > >>> every writeln(), so I don't think it is inefficient. Writeln() will do > >>> a > >>> flush. Whether this happens in .InOutFunc or .FlushFunc is largely > >>> irrelevant. > >> > >> The question is whether the potential change would make any difference. > >> IMHO, the important points are: > >> > >> 1) The point of flushing is making sure the I/O is really performed (the > >> data are sent to the operating system _and_ flushed from internal > >> buffers of the underlying operating system / platform). Doing the latter > >> without the former makes no sense. > >> > >> 2) From semantic point of view, all data should be sent to the final > >> place (block device / console / ...) before the call to Flush is > >> finished (otherwise the following actions may have incorrect results - > >> the program might finish before all data are transmitted, other I/O may > >> be invoked, etc.). > >> > >> From this point of view, the proposed change would only lead to code > >> duplication between FlushFunc and InOutFunc and / or to increased code - > >> e.g. checking FlushFunc being nil before calling InOutFunc just to call > >> InOutFunc (or to perform functionality currently included in InOutFunc) > >> from within FlushFunc anyway. > >> <https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel> > > > > > > Tomas and Michael, thank you for this discussion. I'm starting to think > > the use case I'm considering is perhaps not covered by the current > design. > > I don't understand why you don't do the flush in the InOutFunc ? > > That's what it is for: the text filetype already does the buffering for > you. > So any performance impact is IMO unavoidable: when InOutFunc is called, the > RTL really needs it to clear the buffer. > > Michael. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
On Mon, Jun 8, 2020 at 12:15 PM Tomas Hajny wrote: > On 2020-06-08 11:39, Michael Van Canneyt wrote: > > On Mon, 8 Jun 2020, Christo Crause via fpc-devel wrote: > . > . > >> Thanks for your response Michael. Using InOutFunc to also flush the > >> output > >> buffer will work, but that seems inefficient, since the flush needs to > >> wait > >> until the transmit buffer is empty (at slow UART speeds this could > >> potentially take several ms to complete). Is there a specific reason > >> why > >> the RTL Flush procedure does not call the FlushFunc method? > > > > I checked; That code is so old, no idea. > > > > From what I can see the flush code could be changed to > > > > if Assigned((TextRec(t).FlushFunc) then > > FileFunc(TextRec(t).FlushFunc)(TextRec(t)) > > else > > FileFunc(TextRec(t).InOutFunc)(TextRec(t)); > > > > But keep in mind that the InoutFunc() is only called when actually > > writing > > data, meaning: when the internal text buffer is full or on a terminal > > with > > every writeln(), so I don't think it is inefficient. Writeln() will do > > a > > flush. Whether this happens in .InOutFunc or .FlushFunc is largely > > irrelevant. > > The question is whether the potential change would make any difference. > IMHO, the important points are: > > 1) The point of flushing is making sure the I/O is really performed (the > data are sent to the operating system _and_ flushed from internal > buffers of the underlying operating system / platform). Doing the latter > without the former makes no sense. > > 2) From semantic point of view, all data should be sent to the final > place (block device / console / ...) before the call to Flush is > finished (otherwise the following actions may have incorrect results - > the program might finish before all data are transmitted, other I/O may > be invoked, etc.). > > From this point of view, the proposed change would only lead to code > duplication between FlushFunc and InOutFunc and / or to increased code - > e.g. checking FlushFunc being nil before calling InOutFunc just to call > InOutFunc (or to perform functionality currently included in InOutFunc) > from within FlushFunc anyway. > <https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel> Tomas and Michael, thank you for this discussion. I'm starting to think the use case I'm considering is perhaps not covered by the current design. At the moment I directly call the OS flush function before putting the cpu to sleep and that works; I was just wondering if there is a Pascal way to accomplish this so that a user doesn't have to remember to call a nonstandard function when a Flush function already exist in the RTL. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConsoleIO and flushing buffered output
On Sun, Jun 7, 2020 at 11:54 PM Michael Van Canneyt wrote: > > On Sun, 7 Jun 2020, Christo Crause via fpc-devel wrote: > > > I want to change the _haltproc for freertos ESP controllers to use normal > > write/writeln functionality to send information to standard output. On > > these targets the output is typically buffered serial provided by the OS. > > Text output written just prior to setting the cpu to sleep doesn't get > > sent, hence a flush is needed to complete data transmission before > putting > > the cpu to sleep. Looking at consoleio.OpenIO there doesn't seem to be a > > convenient way to provide a flush helper function. Also the RTL Flush > > procedure calls InOutFunc and not FlushFunc. > > > > What is the proper way to hook a flush helper function into the existing > > RTL infrastructure? > > Simply do this in InoutFunc ? > > Michael. > Thanks for your response Michael. Using InOutFunc to also flush the output buffer will work, but that seems inefficient, since the flush needs to wait until the transmit buffer is empty (at slow UART speeds this could potentially take several ms to complete). Is there a specific reason why the RTL Flush procedure does not call the FlushFunc method? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] ConsoleIO and flushing buffered output
I want to change the _haltproc for freertos ESP controllers to use normal write/writeln functionality to send information to standard output. On these targets the output is typically buffered serial provided by the OS. Text output written just prior to setting the cpu to sleep doesn't get sent, hence a flush is needed to complete data transmission before putting the cpu to sleep. Looking at consoleio.OpenIO there doesn't seem to be a convenient way to provide a flush helper function. Also the RTL Flush procedure calls InOutFunc and not FlushFunc. What is the proper way to hook a flush helper function into the existing RTL infrastructure? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different versions of register name search algorithms used
On Thu, May 21, 2020 at 5:22 PM Sven Barth wrote: > There is a general implementation of the search algorithm in rgbase > which is already used for example by x86/itcpugas.pas as well as > z80/cpubase.pas. So in my opinion the way to go would be to switch the > other targets (as well as x86/itx86int.pas) to use this as well. > Thanks for the suggestion Sven. I've changed the patch for xtensa to call the rgbase search method (issue 0037121). If this patch gets accepted I'll do the same for other targets. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Different versions of register name search algorithms used
While trying to understand bug 0037121I noticed that the predominant search algorithm used for finding register names is a binary search without a match check. My understanding of this algorithm is that it will always run the maximum iterations for the search space before terminating. To understand how this is supposed to work I looked at other target implementations. I realized that this algorithm is used in all but 2 cases: x86 (in itx86int.pas) which uses (what I consider to be) a conventional binary search, and mips which uses a linear search. I don't see a need to have different algorithms for performing what appears to be the same function (search for a string in a sorted list of strings), is this correct? Then, I don't understand why the general search algorithm isn't the one in itx86int.pas. Is there a compelling reason for preferring the 1st algorithm over the conventional binary search? Thirdly, each target has its own implementation of findreg_by_XXXname, is there a reason not to have a single search function shared by all targets? This may require some renaming of current variable lists such as gas_regname_index and int_regname_index etc. to a common convention. Your thoughts on these questions would be appreciated. Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR DWARF Error
On Mon, May 18, 2020 at 8:42 AM Christo Crause wrote: > > On Sun, May 17, 2020 at 10:46 PM Dimitrios Chr. Ioannidis via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Hi, >> >>trying to debug an avr program, I got this error with fpc trunk : >> >> "Reading symbols from >> \Projects\unit_depth_dwarf\unit_depth_dwarf.elf... >> Dwarf Error: Could not find abbrev number 18 in CU at offset 0x111d [in >> module >> G:\Programming\dimitris\Projects\unit_depth_dwarf\unit_depth_dwarf.elf] >> (No debugging symbols found in >> \Projects\unit_depth_dwarf\unit_depth_dwarf.elf)" >> >> Investigating further, I found that when I declare an array type ( only >> ? I need to check further ... ) in a unit that is referenced from >> another unit which in turn is referenced from the main program, I get >> the error, i.e. : >> >> depth_2.pas unit -> has a type declared as an array >> >> depth_1.pas unit -> uses depth_2 unit and declares a variable with the >> type from the unit depth_2 >> >> main.pas -> uses depth_1 only >> >> in such scenario I get the dwarf error . >> > > Looking at the compiler generated assembler (-a) the information is > emitted, but doesn't end up in the final elf. This raises the suspicion > that it is the linker that is dropping the whole of the 2nd unit's debug > information If you add a procedure to unit2 that gets referenced anywhere > else the information is retained in the elf. > A check of the dwarf info in unit_depth_dwarf_depth_2.o (avr-objdump -Wi unit_depth_dwarf_depth_2.o) shows that the dwarf info is there, it is just not linked into the final executable. Hence it is a linker problem in my opinion. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR DWARF Error
On Sun, May 17, 2020 at 10:46 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > >trying to debug an avr program, I got this error with fpc trunk : > > "Reading symbols from > \Projects\unit_depth_dwarf\unit_depth_dwarf.elf... > Dwarf Error: Could not find abbrev number 18 in CU at offset 0x111d [in > module > G:\Programming\dimitris\Projects\unit_depth_dwarf\unit_depth_dwarf.elf] > (No debugging symbols found in > \Projects\unit_depth_dwarf\unit_depth_dwarf.elf)" > > Investigating further, I found that when I declare an array type ( only > ? I need to check further ... ) in a unit that is referenced from > another unit which in turn is referenced from the main program, I get > the error, i.e. : > > depth_2.pas unit -> has a type declared as an array > > depth_1.pas unit -> uses depth_2 unit and declares a variable with the > type from the unit depth_2 > > main.pas -> uses depth_1 only > > in such scenario I get the dwarf error . > Looking at the compiler generated assembler (-a) the information is emitted, but doesn't end up in the final elf. This raises the suspicion that it is the linker that is dropping the whole of the 2nd unit's debug information If you add a procedure to unit2 that gets referenced anywhere else the information is retained in the elf. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and Z80
On Tue, 14 Apr 2020, 08:29 Guillermo, wrote: > Hi Pascaloids, > > I've read in the web forums[1] that FPC may include Zylog Z80 as > target, specifically Sinclair's micro computers, but looking at the > SVN[2] I don't see any Z80 reference. > Look in this branch: https://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/z80/ For the rest of the details Florian and nickysn are likely to know. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Problems building xtensa-freertos RTL in trunk
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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Wed, Apr 1, 2020 at 6:58 PM Christo Crause wrote: > Good idea, the alternative instructions are part of the core ISA so it > should always be supported. > So the updated cgcpu patch attached... diff --git a/compiler/xtensa/cgcpu.pas b/compiler/xtensa/cgcpu.pas index a1fdbede87..25b6cb40b9 100644 --- a/compiler/xtensa/cgcpu.pas +++ b/compiler/xtensa/cgcpu.pas @@ -167,14 +167,26 @@ implementation list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg1,0,8)); OS_S8: begin -list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,7)); +if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then + list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,7)) +else + begin +list.concat(taicpu.op_reg_reg_const(A_SLLI,reg2,reg1,24)); +list.concat(taicpu.op_reg_reg_const(A_SRAI,reg2,reg2,24)); + end; if tosize=OS_16 then list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg2,0,16)); end; OS_16: list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg1,0,16)); OS_S16: - list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,15)); + if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then +list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,15)) + else +begin + list.concat(taicpu.op_reg_reg_const(A_SLLI,reg2,reg1,16)); + list.concat(taicpu.op_reg_reg_const(A_SRAI,reg2,reg2,16)); +end; else conv_done:=false; end; @@ -258,7 +270,13 @@ implementation list.concat(taicpu.op_reg_ref(op,reg,href)); if (fromsize=OS_S8) and not(tosize in [OS_S8,OS_8]) then - list.concat(taicpu.op_reg_reg_const(A_SEXT,reg,reg,7)); + if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then +list.concat(taicpu.op_reg_reg_const(A_SEXT,reg,reg,7)) + else +begin + list.concat(taicpu.op_reg_reg_const(A_SLLI,reg,reg,24)); + list.concat(taicpu.op_reg_reg_const(A_SRAI,reg,reg,24)); +end; if (fromsize<>tosize) and (not (tosize in [OS_SINT,OS_INT])) then a_load_reg_reg(list,fromsize,tosize,reg,reg); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Wed, Apr 1, 2020 at 12:06 AM Sven Barth wrote: > Christo Crause schrieb am Di., 31. März 2020, > 19:45: > >> On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < >> fpc-devel@lists.freepascal.org> wrote: >> >>> Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: >>> >>> I've noticed GCC uses the SLLI + SRAI instructions to perform sign >>> extension on ESP8266. >>> >>> Since different CPUs can support different subsets of the Xtensa >>> instructions do you think a finalizecode type function can be used as a >>> post code generation step to map unsupported instructions to alternative >>> sequences? >>> >>> >>> These are simply different CPU types (-CpXXX or selected by the >>> controller type) which the code generator will handle accordingly. Just >>> like it's done with ARM, AVR and all other platforms. >>> >> >> Attach please find a patch to rtl/embedded/MakeFile* to handle subarch >> similar to avr and others. >> > > Did you manually edit the Makefile or regenerate it from the Makefile.fpc? > If the former then your changes at the top will be overwritten by the next > makefile regeneration. > 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 > Also attached a patch that checks whether the SEXT instruction is >> available for the current subarchitecture, else it generates SLLI + SRAI >> combination. >> > > If SLLI and SRAI are supported by the other processors supported by FPC > then you don't need to check for the processor type, checking against the > capability for SEXT is enough. If some processor does not support SLLI or > SRAI either then this would need to be a capability as well. > Good idea, the alternative instructions are part of the core ISA so it should always be supported. diff --git a/utils/fpcm/fpcmake.ini b/utils/fpcm/fpcmake.ini index 42cd924023..1b3b179cfb 100644 --- a/utils/fpcm/fpcmake.ini +++ b/utils/fpcm/fpcmake.ini @@ -288,6 +288,13 @@ endif override FPCOPT+=-Cp$(SUBARCH) endif +ifeq ($(FULL_TARGET),xtensa-embedded) +ifeq ($(SUBARCH),) +$(error When compiling for xtensa-embedded, a sub-architecture (e.g. SUBARCH=lx106 or SUBARCH=lx6) must be defined) +endif +override FPCOPT+=-Cp$(SUBARCH) +endif + # Full name of the target, including CPU and OS. For OSs limited # to 8.3 we only use the target OS ifneq ($(findstring $(OS_SOURCE),$(LIMIT83fs)),) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: > > I've noticed GCC uses the SLLI + SRAI instructions to perform sign > extension on ESP8266. > > Since different CPUs can support different subsets of the Xtensa > instructions do you think a finalizecode type function can be used as a > post code generation step to map unsupported instructions to alternative > sequences? > > > These are simply different CPU types (-CpXXX or selected by the controller > type) which the code generator will handle accordingly. Just like it's done > with ARM, AVR and all other platforms. > Attach please find a patch to rtl/embedded/MakeFile* to handle subarch similar to avr and others. Also attached a patch that checks whether the SEXT instruction is available for the current subarchitecture, else it generates SLLI + SRAI combination. I post the patches here for review since I'm not sure this is necessarily the style to be followed when checking capabilities. diff --git a/rtl/embedded/Makefile b/rtl/embedded/Makefile index 117f0ea026..914e267df4 100644 --- a/rtl/embedded/Makefile +++ b/rtl/embedded/Makefile @@ -197,6 +197,12 @@ $(error When compiling for mipsel-embedded, a sub-architecture (e.g. SUBARCH=pic endif override FPCOPT+=-Cp$(SUBARCH) endif +ifeq ($(FULL_TARGET),xtensa-embedded) +ifeq ($(SUBARCH),) +$(error When compiling for xtensa-embedded, a sub-architecture (e.g. SUBARCH=lx106 or SUBARCH=lx6) must be defined) +endif +override FPCOPT+=-Cp$(SUBARCH) +endif ifneq ($(findstring $(OS_SOURCE),$(LIMIT83fs)),) TARGETSUFFIX=$(OS_TARGET) SOURCESUFFIX=$(OS_SOURCE) @@ -498,8 +504,10 @@ endif endif ifeq ($(ARCH),xtensa) CPU_SPECIFIC_COMMON_UNITS=sysutils math classes fgl macpas typinfo types rtlconsts getopts lineinfo +ifeq ($(SUBARCH),lx106) CPU_UNITS=esp8266 CPU_UNITS_DEFINED=1 +endif ifeq ($(CPU_UNITS_DEFINED),) $(error No CPUs enabled for given SUBARCH, pass either a SUBARCH or set CPU_UNITS_DEFINED=1 if you know what you are doing) endif diff --git a/rtl/embedded/Makefile.fpc b/rtl/embedded/Makefile.fpc index 0566231c3c..ff89dc336c 100644 --- a/rtl/embedded/Makefile.fpc +++ b/rtl/embedded/Makefile.fpc @@ -223,8 +223,10 @@ endif ifeq ($(ARCH),xtensa) CPU_SPECIFIC_COMMON_UNITS=sysutils math classes fgl macpas typinfo types rtlconsts getopts lineinfo +ifeq ($(SUBARCH),lx106) CPU_UNITS=esp8266 CPU_UNITS_DEFINED=1 +endif ifeq ($(CPU_UNITS_DEFINED),) $(error No CPUs enabled for given SUBARCH, pass either a SUBARCH or set CPU_UNITS_DEFINED=1 if you know what you are doing) endif diff --git a/compiler/xtensa/cgcpu.pas b/compiler/xtensa/cgcpu.pas index a1fdbede87..f3e24b7365 100644 --- a/compiler/xtensa/cgcpu.pas +++ b/compiler/xtensa/cgcpu.pas @@ -167,14 +167,28 @@ implementation list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg1,0,8)); OS_S8: begin -list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,7)); +if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then + list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,7)) +else if current_settings.cputype = cpu_lx106 then + begin +list.concat(taicpu.op_reg_reg_const(A_SLLI,reg2,reg1,24)); +list.concat(taicpu.op_reg_reg_const(A_SRAI,reg2,reg2,24)); + end +else + internalerror(2020033101); if tosize=OS_16 then list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg2,0,16)); end; OS_16: list.concat(taicpu.op_reg_reg_const_const(A_EXTUI,reg2,reg1,0,16)); OS_S16: - list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,15)); + if target_info.abi = abi_xtensa_windowed then +list.concat(taicpu.op_reg_reg_const(A_SEXT,reg2,reg1,15)) + else +begin + list.concat(taicpu.op_reg_reg_const(A_SLLI,reg2,reg1,16)); + list.concat(taicpu.op_reg_reg_const(A_SRAI,reg2,reg2,16)); +end; else conv_done:=false; end; @@ -258,7 +272,15 @@ implementation list.concat(taicpu.op_reg_ref(op,reg,href)); if (fromsize=OS_S8) and not(tosize in [OS_S8,OS_8]) then - list.concat(taicpu.op_reg_reg_const(A_SEXT,reg,reg,7)); + if CPUXTENSA_HAS_SEXT in cpu_capabilities[current_settings.cputype] then +list.concat(taicpu.op_reg_reg_const(A_SEXT,reg,reg,7)) + else if current_settings.cputype = cpu_lx106 then +begin + list.concat(taicpu.op_reg_reg_co
Re: [fpc-devel] Error building xtensa rtl
On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: > > > On Sun, Mar 29, 2020 at 11:00 PM Florian Klämpfl > wrote: > >> Am 29.03.20 um 22:46 schrieb Christo Crause via fpc-devel: >> > It seems that a different instruction sequence should be used for sign >> > extension for the lx106 subarch. >> >> Ok, I see. Let me first integrate everything done so far in trunk, then >> we can continue with the details :) >> > > I've noticed GCC uses the SLLI + SRAI instructions to perform sign > extension on ESP8266. > > Since different CPUs can support different subsets of the Xtensa > instructions do you think a finalizecode type function can be used as a > post code generation step to map unsupported instructions to alternative > sequences? > > > These are simply different CPU types (-CpXXX or selected by the controller > type) which the code generator will handle accordingly. Just like it's done > with ARM, AVR and all other platforms. > Make sense. The make files are not current set up like that for xtensa. I'll make a patch to make xtensa-embedded work like avr etc with regards to subarch. This will then make it easier to check for cpu_capabilities in the compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Sun, Mar 29, 2020 at 11:00 PM Florian Klämpfl wrote: > Am 29.03.20 um 22:46 schrieb Christo Crause via fpc-devel: > > It seems that a different instruction sequence should be used for sign > > extension for the lx106 subarch. > > Ok, I see. Let me first integrate everything done so far in trunk, then > we can continue with the details :) > I've noticed GCC uses the SLLI + SRAI instructions to perform sign extension on ESP8266. Since different CPUs can support different subsets of the Xtensa instructions do you think a finalizecode type function can be used as a post code generation step to map unsupported instructions to alternative sequences? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Sun, Mar 29, 2020 at 8:38 AM Christo Crause wrote: > On Sat, Mar 28, 2020 at 11:04 PM Florian Klämpfl > wrote: > >> Am 28.03.20 um 21:33 schrieb Christo Crause via fpc-devel: >> > When building the xtensa rtl with >> > >> > make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CROSSOPT=-Cacall0 >> > CPU_TARGET=xtensa OS_TARGET=embedded SUBARCH=esp8266 >> > BINUTILSPREFIX=xtensa-lx106-elf- >> > >> > the following errors are returned by as: >> > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler >> > messages: >> > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:203: Error: >> > unknown opcode or format name 'sext' >> > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:204: Error: >> > unknown opcode or format name 'sext' >> > >> > When building with CROSSOPT=-Cawindowed as complains about other errors: >> > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler >> > messages: >> > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:11: Error: >> > unknown opcode or format name 'retw' >> > >> > Any tips on how to build the xtensa rtl? >> >> I didn't care about the call0 abi yet. Is it used by the esp8266? >> > > Inspecting some C examples I've compiled with PlatformIO for ESP8266 shows > use of callx0 for the non-rtos SDK. My goal was just to test the cross > compiler, but the RTL failed with error 2020031404 (in > tcpuparamanager.init_values) which seems to suggest an ABI must be > specified. Neither of the options I tried satisfied the assembler however. > According to the Xtensa ISA 4.3.8 the SEXT instruction is optional (and some others too) and apparently not implemented for ESP8266 according to core-isa.h in ESP8266_RTOS_SDK ( https://github.com/espressif/ESP8266_RTOS_SDK/blob/master/components/esp8266/include/xtensa/config/core-isa.h). This explains why xtensa-lx106-elf-as does not recognise the SEXT instruction. It seems that a different instruction sequence should be used for sign extension for the lx106 subarch. Also core-isa.h indicates XCHAL_HAVE_WINDOWED = 0, which I take to mean that the LX106 toolchain doesn't know/implement the windowed ABI, which explains why setting the FPC ABI to windowed caused as to flag retw as unknown. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building xtensa rtl
On Sat, Mar 28, 2020 at 11:04 PM Florian Klämpfl wrote: > Am 28.03.20 um 21:33 schrieb Christo Crause via fpc-devel: > > When building the xtensa rtl with > > > > make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CROSSOPT=-Cacall0 > > CPU_TARGET=xtensa OS_TARGET=embedded SUBARCH=esp8266 > > BINUTILSPREFIX=xtensa-lx106-elf- > > > > the following errors are returned by as: > > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler > > messages: > > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:203: Error: > > unknown opcode or format name 'sext' > > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:204: Error: > > unknown opcode or format name 'sext' > > > > When building with CROSSOPT=-Cawindowed as complains about other errors: > > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler > > messages: > > /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:11: Error: > > unknown opcode or format name 'retw' > > > > Any tips on how to build the xtensa rtl? > > I didn't care about the call0 abi yet. Is it used by the esp8266? > Inspecting some C examples I've compiled with PlatformIO for ESP8266 shows use of callx0 for the non-rtos SDK. My goal was just to test the cross compiler, but the RTL failed with error 2020031404 (in tcpuparamanager.init_values) which seems to suggest an ABI must be specified. Neither of the options I tried satisfied the assembler however. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Error building xtensa rtl
When building the xtensa rtl with make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CROSSOPT=-Cacall0 CPU_TARGET=xtensa OS_TARGET=embedded SUBARCH=esp8266 BINUTILSPREFIX=xtensa-lx106-elf- the following errors are returned by as: /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler messages: /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:203: Error: unknown opcode or format name 'sext' /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:204: Error: unknown opcode or format name 'sext' When building with CROSSOPT=-Cawindowed as complains about other errors: /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s: Assembler messages: /home/christo/fpc/3.3.1/rtl/units/xtensa-embedded/system.s:11: Error: unknown opcode or format name 'retw' Any tips on how to build the xtensa rtl? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] XTensa support question
On Tue, 24 Mar 2020, 00:42 Sven Barth, wrote: > Christo Crause via fpc-devel schrieb am > Mo., 23. März 2020, 18:18: > >> 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? >> > > Once FPC support for the Espressif SDK is done the Ultibo devs can try to > port their code to the Xtensa as well if they want. That is their choice, > not ours. > Thanks. I realise Ultibo is an independent project, I am just hoping for a full Pascal development stack. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] XTensa support question
On Mon, Mar 23, 2020 at 7:36 PM Florian Klämpfl wrote: > 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. > That is good news! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] XTensa support question
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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Macro expansion in assembler code
I noticed that macro's in assembler code is not expanded before the code is
parsed. Is there are technical reason this is not done, or is it merely a
historical artefact?
My question is prompted by the latest assembler code modifications to
accommodate avrtiny subarch in the AVR RTL, where the following type of
snippets are used in several places to accommodate the differences in
registers:
{$ifdef CPUAVR_16_REGS}
in r16,63
{$else CPUAVR_16_REGS}
in r0,63
{$endif CPUAVR_16_REGS}
It would seem neater to use a macro (defined by compiler in this case) to
indicate which register should be used as temp reg (similar to GCC):
{$ifdef CPUAVR_16_REGS}
{$define AVR_TEMPREG := r16}
{$else CPUAVR_16_REGS}
{$define AVR_TEMPREG := r0}
{$endif CPUAVR_16_REGS}
The assembler code can then more cleanly be written without further
conditional checks by using the macro:
in AVR_TEMPREG, 63
Similarly reference to the zero register (r1 or r17) can benefit from being
defined through a macro.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Support for AVR subarch avrxmega3 (megaAVR 0, tinyAVR 0/1 series)
On Sun, Jan 19, 2020 at 7:00 PM Florian Klämpfl wrote: > Am 19.01.20 um 08:20 schrieb Christo Crause via fpc-devel: > > I would like to offer support for the relatively new AVR 8-bit > > subarchitecture avrxmega3 which includes the following series: megaAVR > > 0, tinyAVR 0 and 1. This adds 35 new controllers to FPC's repertoire. > > The current state can be viewed in a git branch > > (https://github.com/ccrause/freepascal/tree/avrxmega3). I can also > > prepare a patch (perhaps two: compiler and rtl separately) if it is > > accepted into trunk. > > If the patch quality is fine and the embedded units aren't too big (not > MB scale) I see no reason not to do so. > I have split the patch into 3 parts in issue 0036616. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR subarch avrtiny
On Sun, Jan 19, 2020 at 7:09 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > >is it possible to change the subarch name from avrtiny to avrtiny10 > as per AVR libc ? > > ( > > https://www.microchip.com/webdoc/avrlibcreferencemanual/using_tools_1using_avr_gcc_mach_opt.html > ) > I suspect that reference is in need of an update. The date at the top says it is from 2015 (it doesn't mention avrxmega3). The GNU reference for avr options (https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html) says avrtiny. I would assume that the GNU documentation should be up to date (it is copyrighted 2020). The current binutils on my Linux also expect avrtiny. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Support for AVR subarch avrxmega3 (megaAVR 0, tinyAVR 0/1 series)
I would like to offer support for the relatively new AVR 8-bit subarchitecture avrxmega3 which includes the following series: megaAVR 0, tinyAVR 0 and 1. This adds 35 new controllers to FPC's repertoire. The current state can be viewed in a git branch ( https://github.com/ccrause/freepascal/tree/avrxmega3). I can also prepare a patch (perhaps two: compiler and rtl separately) if it is accepted into trunk. There are very few differences between the classical avr8 and this new architecture. The only differences I have picked up and included in the compiler so far: * Memory map excludes core register file, so I/O register addresses start at offset 0. * 16-bit I/O register read/write order is different. Both read and write operations should access low register first. Notes on controller units: * Some interrupt names have aliases, I don't know how to specify an alias for interrupt vectors so I picked the first name in the device file. * The I/O registers are grouped per peripheral, this naturally leads to using records to group the individual registers. There are a whole bunch of bit names with clashes between registers. To work around name clashes I decided to use objects and included the named bits inside the objects. An example of writing named bits to a register: ADC0.CTRLC := TADC.SAMPCAPbm or TADC.REFSEL_VDDREF or TADC.PRESC_DIV256; Best wishes, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Updating compiler test suite for limited AVR features
I ran the compiler test suite for the avr-embedded target to see how a modification I made impacts things. There are however so many compilation failures (over 1100) due to unsupported features (floating point support, sysutils, variants, classes etc.) that it is difficult to spot relevant failures. Filtering out floating point testing can be done by checking for the FPUNONE definition. I'm not sure whether it is possible to filter out tests for other features, particularly functionality that maps to a runtime error if EXCLUDE_COMPLEX_PROCS is defined. I can scan through all the tests searching for floating point types and ifdef the floating point code using ifndef FPUNONE. Other tests involving unsupported keywords/units can be skipped by adding %SKIPCPU=AVR to these tests, but this is in my mind not a future proof way of filtering functionality to test. I also want to add timeouts (say 60s) for the more intensive tests such as test/tindex.pp. Some tests may require reducing the test space so that a simulator can complete the tests in a reasonable time, i.e. test/cg/tmoddiv2.pp performs several sets of 2 random tests, but takes an enormous amount of time to run through a simulator. Obviously this is an important test to prove correctness of integer math, but I would like to reduce the loop count to 200 for AVR so that the test can complete in about a minute or two. Does anyone have better ideas on how to filter out tests for unsupported features that will be future proof (i.e. if functionality is added to AVR then the relevant tests would automatically be active)? Would these kind of modifications be accepted into trunk (at least in principle)? I'll create a git repository for this work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Wrong" evaluation of longbool on AVR
On Sat, 7 Sep 2019, 22:20 Florian Klämpfl, wrote: > > Thanks for the analysis, I fixed it already, see r42938. > That was quick, thank you. > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] "Wrong" evaluation of longbool on AVR
I am investigating test suite failures for the avr-embedded target. The first genuine failure is test/taddbool.pp (there are also a bunch of incorrect exit values and other failures due to missing features such as float, random, ansi/widestring etc.). This test fails on the last expression (longbool XOR longbool). The following is a stripped down test case illustrating the failure: Program TAddBool; var lb1, lb2: longbool; begin lb1 := true; lb2 := true; if lb1 xor lb2 then Halt(1) else Halt(0); end. >From the node report (thanks Kit!) it appears that the compiler first converts the longbools to boolean8, then perform the XOR, then convert the boolean8 result back to longbool before evaluating the if condition. In this last type conversion there appear to be an error (with reference to the attached assembler output): after label .Lj5 a 32 bit bool is recreated from the result of the 8 bit XOR node. Note that r18 contains the result of the 8 bit XOR result, however registers r19 - r21 are used without initialization. R19 in this example contains the result of converting LB2 to an 8 bit bool, leading to the observed incorrect result. Is this analysis correct? If so, is this a code generation issue limited to avr, or is it a higher level problem which affects other processor types? Would someone be willing to give me pointers on how to fix this if the fix is not too involved? taddbool.s Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Guidance for code generation for shift operations for AVR target
On Mon, Aug 19, 2019 at 10:36 PM Florian Klaempfl wrote: > Am 19.08.2019 um 22:20 schrieb Christo Crause: > > I'm interested in trying to improve the code generated for shift > > operations (in particular involving a compile time constant shift) for > > the AVR target. > For me the idea looks good, actually, I planned once to do the same, but > got stuck for time reasons with the beginnings you discovered. > Attached a patch that optimizes SHL and SHR for constant right value for comment. Note that I haven't implemented support for SAR, ROL or ROR, these operations should fall through to the current code path. A heuristic to decide when loop unrolling is favoured is also included, taking into account -Os. Some of the details behind the optimizations are discussed here: https://github.com/ccrause/freepascal/wiki/Optimizing-code-generation-for-shift-with-compile-time-constant One remaining optimization I would like to implement is to eliminate loading part of a variable to a register if it is eliminated by the shift amount. The loading of the variable and saving of the result from/to memory happens before tcgavr.a_op_const_reg_reg gets called. Is there a way to remove such a redundant load instruction from tcgavr.a_op_const_reg_reg? Or at least mark it for removal at a later stage ( peephole optimizer)? I assume it would make sense to also include SAR support in this patch, since it could be generated by div? best wishes, Christo diff --git compiler/avr/cgcpu.pas compiler/avr/cgcpu.pas index 4be4f4823e..ba6a06427e 100644 --- compiler/avr/cgcpu.pas +++ compiler/avr/cgcpu.pas @@ -438,6 +438,11 @@ unit cgcpu; procedure tcgavr.a_op_const_reg_reg(list: TAsmList; op: TOpCg; size: tcgsize; a: tcgint; src, dst: tregister); + var + tmpSrc, tmpDst, countreg: TRegister; + b, b2, i, j: byte; + s1, s2, t1: integer; + l1: TAsmLabel; begin if (op in [OP_MUL,OP_IMUL]) and (size in [OS_16,OS_S16]) and (a in [2,4,8]) then begin @@ -451,6 +456,88 @@ unit cgcpu; a:=a shr 1; end; end + else if (op in [OP_SHL, OP_SHR]) and (a > 0) then // a = 0 get eliminated later by tcg.optimize_op_const + begin + b := a div 8; // number of bytes to shift + + // copy from src to dst accounting for shift offset + for i := 0 to (tcgsize2size[size]-b-1) do + if op = OP_SHL then + a_load_reg_reg(list, OS_8, OS_8, + GetOffsetReg64(src, NR_NO, i), + GetOffsetReg64(dst, NR_NO, i+b)) + else + a_load_reg_reg(list, OS_8, OS_8, + GetOffsetReg64(src, NR_NO, i+b), + GetOffsetReg64(dst, NR_NO, i)); + + b2 := a mod 8; // remaining bit shifts + if b2 > 0 then + begin + // Cost of loop + s1 := 3 + tcgsize2size[size] - b; + t1 := b2*(tcgsize2size[size] - b + 3); + //Cost of loop unrolling, t2 = s2 + s2 := b2*(tcgsize2size[size] - b); + + if ((cs_opt_size in current_settings.optimizerswitches) and (s1 < s2)) or +(((s2 - s1) - t1/s2) > 0) then + begin + // Shift non-moved bytes in loop + current_asmdata.getjumplabel(l1); + countreg:=getintregister(list,OS_8); + a_load_const_reg(list,OS_8,b2,countreg); + cg.a_label(list,l1); + if op = OP_SHL then + list.concat(taicpu.op_reg(A_LSL,GetOffsetReg64(dst, NR_NO, b))) + else + list.concat(taicpu.op_reg(A_LSR,GetOffsetReg64(dst, NR_NO, tcgsize2size[size]-1-b))); + + if size in [OS_S16,OS_16,OS_S32,OS_32,OS_S64,OS_64] then + begin + for i:=2+b to tcgsize2size[size] do + if op = OP_SHL then + list.concat(taicpu.op_reg(A_ROL,GetOffsetReg64(dst,NR_NO,i-1))) + else + list.concat(taicpu.op_reg(A_ROR,GetOffsetReg64(dst, NR_NO,tcgsize2size[size]-i-b))); + end; + list.concat(taicpu.op_reg(A_DEC,countreg)); + a_jmp_flags(list,F_NE,l1); + // keep registers alive + list.concat(taicpu.op_reg_reg(A_MOV,countreg,countreg)); + end + else + begin + // Unroll shift loop over non-moved bytes + for j := 1 to b2 do + begin + if op = OP_SHL then + list.concat(taicpu.op_reg(A_LSL, +
Re: [fpc-devel] problem compiling compiler
On Wed, Aug 21, 2019 at 4:07 PM Marģers . via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Hi, > i used simple script for compiling compiler > > export PP=/home/user/fpc304/lib/fpc/3.0.4/ppcx64 > make singlezipinstall OS_TARGET=linux > CPU_TARGET=x86_64OPT=" > -Fu/home/user/fpc304/lib/fpc/3.0.4/units/x86_64-linux/rtl/" > > Reason of "export PP=" is that i don't have > installed fpc, so i have to specify path where to > find it. > Script was fine some time ago, but now it can not > find compiler: > > Makefile:135: *** Compiler > /home/user/where/is/my/copy/of/fpc/compiler/ppcx64 > not found. Stop. > > > Can i improve my script to actually work or is it > some sort of makefile bug? > The error message does not agree with your exported value of PP, so something else is messing up. An alternative to the export command is to specify the path to the compiler as a parameter to make, similar to the rest of the parameters you pass to make. To troubleshoot use the info command for make to see how the various variables are configured: make info PP=/home/user/fpc304/lib/fpc/3.0.4/ppcx64 If the compiler is found, it should be reported as the first line printed after == Configuration info == ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Guidance for code generation for shift operations for AVR target
I'm interested in trying to improve the code generated for shift operations (in particular involving a compile time constant shift) for the AVR target. The AVR processor doesn't have a barrel shifter, instead it can only shift a single bit position per clock cycle. Currently the compiler by default generates a bit shift loop where the loop is executed n times to push a value by n bits. The only optimization I noticed for the case of shifting a value by a compile time constant is in Tcg.a_op_const_reg_reg where an 8 bit shift of a 16 bit value is converted to copying the low byte of the left operand into the high byte of the result, and setting the low byte of the result to 0. I would like to extend this type of optimization to cover more cases - the obvious extension is to convert all shifts by 8 bit multiples by corresponding byte moves. A more general approach (which I've got working for shl as concept) is to at least convert all 8 bit multiples as byte moves, then just do the last few bit shifts (if any) either as an unrolled loop (e.g. as implemented in tcgavr.a_op_const_reg_internal) or by generating the conventional shift loop (as implemented in tcgavr.a_op_reg_reg_internal). At the moment I've implemented the this logic in tcgavr.a_op_const_reg_reg. I first check if I can generate smaller code compared to a shift loop and if not, the code calls the inherited method a_op_const_reg_reg which basically follows the existing path (see also attached patch) The code generator is complex to follow for me, since the functionality is kind of normalized and distributed across generic and CPU specific parts, and code flow jumps around up and down the inheritance chain. I therefore have some questions around this proposed modification and implementation in the code generator for which I would like some guidance on: * Is tcgavr.a_op_const_reg_reg the correct place for this type of functionality? * Am I messing up something else by effectively moving most of the code generation for this case higher up the call chain? * Am I missing some other path which could also benefit from this optimization? * Should I try and generate different code depending on whether -Os is specified or not (e.g. perform more loop unrolling if -Os is not specified)? * Any comments on the patch, which is a work in progress? best wishes, Christo diff --git compiler/avr/cgcpu.pas compiler/avr/cgcpu.pas index 4be4f4823e..355e204bf7 100644 --- compiler/avr/cgcpu.pas +++ compiler/avr/cgcpu.pas @@ -438,6 +438,9 @@ unit cgcpu; procedure tcgavr.a_op_const_reg_reg(list: TAsmList; op: TOpCg; size: tcgsize; a: tcgint; src, dst: tregister); + var + tmpSrc, tmpDst: TRegister; + b, i, j: byte; begin if (op in [OP_MUL,OP_IMUL]) and (size in [OS_16,OS_S16]) and (a in [2,4,8]) then begin @@ -451,6 +454,43 @@ unit cgcpu; a:=a shr 1; end; end + // Word size wins up to remainder = 3 + // Dword size wins up to remainder = 2 + else if (op = OP_SHL) and (a > 0) // a = 0 get eliminated later by tcg.optimize_op_const + and ((a mod 8) * tcgsize2size[size] <= 8) then // remaining shifts short enough for unrolled loop + begin + b := a div 8; // number of bytes to shift + // first fill LSB with 0 + tmpSrc := src; + tmpDst := dst; + for i := 1 to b do + begin + a_load_const_reg(list,OS_8,0,tmpDst); + tmpDst := GetNextReg(tmpDst); + end; + + for i := b+1 to tcgsize2size[size] do + begin + a_load_reg_reg(list,OS_8,OS_8,tmpSrc,tmpDst); + if i < tcgsize2size[size] then // don't retrieve next reg if on last iteration + begin + tmpSrc := GetNextReg(tmpSrc); + tmpDst := GetNextReg(tmpDst); + end; + end; + + b := a mod 8; + if b > 0 then + begin + for j := 1 to b do + begin + list.concat(taicpu.op_reg(A_LSL, dst)); + if not(size in [OS_8, OS_S8]) then + for i := 2 to tcgsize2size[size] do + list.concat(taicpu.op_reg(A_ROL,GetOffsetReg64(dst, NR_NO, i-1))); + end; + end; + end else inherited a_op_const_reg_reg(list,op,size,a,src,dst); end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR - redundant mov followed by ldi instruction
On Tue, Jul 23, 2019 at 9:49 PM Christo Crause wrote: > The following test code generates a redundant mov instruction which seems > to be related to a situation with an unused procedure parameter and the > inc() procedure: > > program testRegAlloc; > var > a, b: byte; > procedure testDummyParam(var x: byte); > begin > inc(a); > end; > begin > testDummyParam(b); > end. > > The generated code for testDummyParam: > mov r18, r24 > ldi r18, 0x00 ; 0 > ldi r19, 0x01 ; 1 > movw r30, r18 > ld r20, Z > inc r20 > movw r30, r18 > st Z, r20 > ret > > Moving r24 to r18 is redundant since it will be overwritten by the next > ldi instruction. Attached is a patch that can identify this situation and > eliminate the redundant mov. Is it the correct approach to fix this in the > peephole optimizer, or can it be fixed at an earlier stage? > After some more testing i think my approach to fixing this is completely backwards. The issue (of redundant code generation) is probably better addressed upstream (at node level?) by identifying that the parameter is unused and hence code should not be generated in the first place. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] AVR - redundant mov followed by ldi instruction
The following test code generates a redundant mov instruction which seems
to be related to a situation with an unused procedure parameter and the
inc() procedure:
program testRegAlloc;
var
a, b: byte;
procedure testDummyParam(var x: byte);
begin
inc(a);
end;
begin
testDummyParam(b);
end.
The generated code for testDummyParam:
mov r18, r24
ldi r18, 0x00 ; 0
ldi r19, 0x01 ; 1
movw r30, r18
ld r20, Z
inc r20
movw r30, r18
st Z, r20
ret
Moving r24 to r18 is redundant since it will be overwritten by the next ldi
instruction. Attached is a patch that can identify this situation and
eliminate the redundant mov. Is it the correct approach to fix this in the
peephole optimizer, or can it be fixed at an earlier stage?
best wishes,
Christo
Index: compiler/avr/aoptcpu.pas
===
--- compiler/avr/aoptcpu.pas (revision 42485)
+++ compiler/avr/aoptcpu.pas (working copy)
@@ -1076,7 +1076,22 @@
GetNextInstruction(hp1,hp1);
if not assigned(hp1) then
break;
-end;
+end
+{
+ This removes the mov from
+ mov rX,...
+ ldi/s rX,...
+}
+else if GetNextInstruction(p,hp1) and
+ (MatchInstruction(hp1,A_LDI) or MatchInstruction(hp1,A_LDS)) and
+ (taicpu(p).oper[0]^.typ = top_reg) and
+ (taicpu(hp1).oper[0]^.typ = top_reg) and
+ (taicpu(p).oper[0]^.reg = taicpu(hp1).oper[0]^.reg) then
+ begin
+DebugMsg('Peephole MovLDx2LDx performed', p);
+
+result:=RemoveCurrentP(p);
+ end;
end;
A_SBIC,
A_SBIS:
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Patch for AVR DWARF information
Today is the anniversary of bug report 0033914. It took me a couple of tries, but I think I eventually arrived at a decent patch for this issue some time ago. Can I interest any of the core developers to evaluate this patch? Best regards, Christo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] avr-gdb and dwarf 3
On Fri, Jun 7, 2019 at 1:02 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: >AFAIU, you build the AVR RTL with dwarf 3 ( doesn't support dwarf 2 ) > if you want RTL debugging information. But, the avr-gdb ( at least the > latest 3.5.4.1709 from Microchip ( Atmel ) ) supports only dwarf 2. > >How can I debug the RTL ? > There are more recent versions on Microchip's website (3.6.2: https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers scroll down page). But even this has an old version of avr-gdb (7.8). Probably better to compile an 8.x version of gdb with this patch: https://sourceware.org/ml/gdb-patches/2016-03/msg00318.html. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver
On Wed, Jun 5, 2019 at 8:21 AM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > Στις 2/6/2019 5:46 μ.μ., ο Jeppe Johansen έγραψε: > > On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote: > > procedure AtomicWnrite(var value: word; new_value: word); inline; > > var > > b: Byte; > > begin > > b:=avr_save; > > value:=new_value; > > avr_restore(b); > > end; > > > > function AtomicRead(var value: word): word; inline; > > var > > b: Byte; > > begin > > b:=avr_save; > > AtomicRead:=value; > > avr_restore(b); > > end; > > Can I use those inside an interrupt handler ? What about nested interrupts > ? > In my opinion not required for a normal ISR, since the global interrupt flag is disabled anyway. Obviously if you enable the global interrupt flag inside an ISR tor nesting interrupts then you would need the above functions for atomic access to variables. For new architectures such as tinyAVR1 or megaAVR0 series the interrupt systems are a bit more involved (not sure how one would ensure atomic access if a normal ISR is interrupted by a non-maskable interrupt). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver
On Mon, Jun 3, 2019 at 9:21 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I build a simple blinky for a atmega4809 and it worked. I thought that I > informed you regarding this but it seems that I forgot. > > If you want I can run some tests. You can send me tests that you think > that are appropriate for those mcu's. > > I've soldered a atmega4809 on a breakout pcb and of course I can solder > the others atmega3208/9 and the athemega4808 for testing . > Good news. I'll have t think what is different enough between the old style mega/tiny and the new xmega style controllers to warrant specific testing... > PS: I'm curious if there is, a test suite for testing the compiler in such > hardware or how can someone create such a test ... > The test suite seems quite flexible, it is may be possible to build in a hardware interface (such as a serial port) to test controller responses. Another alterive could be to run code through a simulator such as simavr or fp-simavr. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver
On Mon, Jun 3, 2019 at 11:16 AM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > >> and add support for the avrxmega3 subarch, atmega 3208, > >> 3209, 4808, 4809 ( from Christo Crause's repository > >> https://github.com/ccrause/freepascal.git [7] ) ? > > Any news, plans for those mcu's ( I don't want to push my luck ... )? > AFAIK the code hasn't been tested on an actual mcu from this family, so it is probably not yet ready for inclusion in a stable version. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR target on trunk does not compile for me
On Mon, Jun 3, 2019 at 12:00 PM Michael Ring wrote: > Last question: Is avr6 the only subarch that has enough memory for > enabling strings? I am a Noob when it comes to avr, but I guess there > should be more subarchs that have more memory, I today saw some ATTINY > Chips with 32kB of Flash > > Michael > One could enable extra string functionality (at least ansistring) for avr5 and avr51. It doesn't add to the final compiled size if one doesn't use the functionality. It does pull in a substantial amount of code once you start using it (2 - 4 KB in a very simple test, depends of course on the number of different types of string conversions). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
