Re: [fpc-devel] AVR calling convention for shortstring result type

On 11 Dec 2017 11:44 PM, "Florian Klämpfl" wrote: > > Am 11.12.2017 um 21:58 schrieb Christo: > > It appears from the generated code as if the function result location is assigned before the > > function is called, with the reference to the function result passed as first

Re: [fpc-devel] Testing!

Kit, I suspect my 2nd reply to the mentioned topic was sent to your email address only. Your replies in that thread is visible in the archive: http://lists.freepascal.org/pipermail/fpc-devel/2018-May/thread.html#38912 P.s. It took quite a while before receiving an acknowledgement from the

Re: [fpc-devel] Optimization theory

The penalty for separate div & mod operations for your scenario is severe on targets that require software implementation (e.g. 8 bit AVR). There is a DivMod implementation in unit math, would be useful if this is available in system. On Sun, 17 Jun 2018, 00:22 J. Gareth Moreton, wrote: > >

Re: [fpc-devel] Signed division

On Fri, Jun 1, 2018 at 11:13 AM, J. Gareth Moreton < gar...@moreton-family.com> wrote: > Hi everyone, > > I'm starting to make some modifications to the optimizer so it optimises > div and mod operations on signed integers (I've done unsigned integers > already). One question that I've stumbled

Re: [fpc-devel] AVR assembler code consistency checking

On Mon, Jan 22, 2018 at 11:11 PM, Florian Klämpfl wrote: > > To me it looks good. I propose to commit if it breaks no existing code, > time will tell if the checks > are ok :) Great news, do I have to create a bug report with the patch? I also have a test program with

Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures

On Sun, Jul 22, 2018 at 12:55 PM, Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Am 22.07.2018 um 10:31 schrieb Christo: > >> I'm trying to change the build process for target AVR so that different >> sub architectures end up >> in different subfolders. At the moment the

Re: [fpc-devel] Soft Float for AVR

On Wed, 18 Jul 2018, 14:33 Dimitrios Chr. Ioannidis via fpc-devel, < fpc-devel@lists.freepascal.org> wrote: > Hi, > >AFAIU, the AVR architecture doesn't support floating point variables. > >I want to ask if soft float support ( like ARM ) is planned. Does > anyone work or plan to work on

Re: [fpc-devel] Lazarus IDE / Packages - SetAlternativeCompile for Before and After

On Sun, 9 Sep 2018, 18:30 Mathias, wrote: > Hello > Lazarus team, > > > > i build an AVR package for the Lazarus IDE. > > It is absolutely necessary, that I can enter something with > compiler commands, with "afterwards". There comes in an >

Re: [fpc-devel] max_operands for AVR after rev 40170

On Fri, Nov 2, 2018 at 12:51 PM Pierre Muller wrote: > Hopefully someone else can explain that discrepancy, > I have no idea why this exists, > it might be simply related to the CPU instructions > with most parameters that are considered for optimization! > Thanks for the backgroup Pierre.

Re: [fpc-devel] max_operands for AVR after rev 40170

On Sat, Nov 3, 2018 at 8:31 AM Christo Crause wrote: > On Fri, Nov 2, 2018 at 12:51 PM Pierre Muller > wrote: > >> Hopefully someone else can explain that discrepancy, >> I have no idea why this exists, >> it might be simply related to the CPU instructi

[fpc-devel] max_operands for AVR after rev 40170

I've noted that r.40170 defines MAX_OPTS_2 for AVR in aoptutils.pas. Should the constant max_operands in avr/cpubase.pas not also be changed to 2 to be internally consistent? If so then I can adapt avr/raavr.pas to be consistent with a maximum number of operands of 2.

Re: [fpc-devel] AVR ATMEGA4808 ATMEGA4809

On Mon, Nov 5, 2018 at 12:37 AM Dimitrios Chr. Ioannidis < d.ioanni...@nephelae.eu> wrote: > Στις 4/11/2018 9:07 μμ, ο Christo Crause έγραψε: > > > I can share a patch if you want to test the compiler with an actual > > device or simulator. > > That would be nic

Re: [fpc-devel] AVR ATMEGA4808 ATMEGA4809

I made a quick modification today and it seems doable to add these devices without much change. Compared the code generated for a basic test between modified FPC and avr-gcc with atmega4808 updated from latest update pack and the binaries seem to match quite well. A bit more effort is required

Re: [fpc-devel] Writing to 16 bit timer registers on AVR (bug #34721)

On Thu, 27 Dec 2018, 23:37 Florian Klämpfl > Thanks, I have applied it in r40678 (with a small fix to make it > compilable). I am not aware of other places where > changes could be necessary. Apologies for missing the tempreg2 declaration in the patch. I make modifications to the compiler in

[fpc-devel] Writing to 16 bit timer registers on AVR (bug #34721)

According to AVR manuals 16 bit timer registers share a temp register which requires a specific sequence for reading/writing: "To do a 16-bit write, the high byte must be written before the low byte. For a 16-bit read, the low byte must be read before the high byte." - from atmega328p 15.3

Re: [fpc-devel] Linux compilation question

On Sat, 1 Dec 2018, 01:37 J. Gareth Moreton Actually still having lots of problems here. Can anyone give me some > advice? Admittedly my skills with Linux are lacking, but I would like to > get it to build on x86_64-linux before I submit my patch to everyone. > > What I've discovered so far is

Re: [fpc-devel] AVR HeapSize and StackSize

On Sat, Mar 23, 2019 at 9:37 PM Florian Klämpfl wrote: > Am 23.03.2019 um 11:52 schrieb Dimitrios Chr. Ioannidis via fpc-devel: > > Hi, > > > > I'm using the heapmgr unit and, for the atmega328p, AFAIU the default > heap size is 80 bytes. Cause it's too small for > > my needs, I changed to 512

Re: [fpc-devel] Packed record integers and x86_86

On Wed, 27 Mar 2019, 19:27 DJ Coertzen, wrote: > Hi there, > > I need a solution for a packed record containing 4-byte 32-bit integers > and cardinals, and other byte 8 bit and word 16 bit sized variables to > overlay over a stream. > > Example: > *type* > * TMyBinaryHeader = packed record* > *

Re: [fpc-devel] Aligned dynamic arrays

On Thu, 28 Mar 2019, 20:34 Ryan Joseph, wrote: > Now I’m using “cd /rtl; make all FPC=/path/to/compiler” to build the RTL > but this is obviously slow and unnecessary. Is there a quicker way to build > just the unit which contains dynarr.inc and have all the objects files to > be put in the

Re: [fpc-devel] AVR HeapSize and StackSize

On Sat, Mar 23, 2019 at 9:37 PM Florian Klämpfl wrote: > Am 23.03.2019 um 11:52 schrieb Dimitrios Chr. Ioannidis via fpc-devel: > > Hi, > > > > I'm using the heapmgr unit and, for the atmega328p, AFAIU the default > heap size is 80 bytes. Cause it's too small for > > my needs, I changed to 512

Re: [fpc-devel] XML node dump feature

On Thu, 7 Feb 2019, 03:16 J. Gareth Moreton I hope it proves useful. It's at least giving me some insight into how > some things are set up. > > Gareth aka. Kit > This sounds useful, especially for someone like me who isn't that familiar with the compiler but poke around in the compiler

Re: [fpc-devel] Cortex-M0 (SAMD21G18A) and gcc-arm-none-eabi-8-2018-q4-major-win32

On Sun, May 26, 2019 at 9:16 AM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > "G:\Programming\dimitris\tools\gcc-arm-none-eabi\bin\arm-none-eabi-objcopy.exe: > G:\Programming\dimitris\tools\mbf\Samples\Blinky\Blinky.hex 64-bit address > 0x4b4fa3 out of

Re: [fpc-devel] AVR target on trunk does not compile for me

On Mon, Jun 3, 2019 at 4:43 AM Michael Ring wrote: > Is this issue also known to you? I am trying to build avr6 support: > > BINUTILSPREFIX=avr- ; CROSSOPT="-O- -g -dDEBUG" > SUBARCH=avr6 > make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=avr > SUBARCH=$SUBARCH

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);

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 (

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

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

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

Re: [fpc-devel] AVR target on trunk does not compile for me

On Sun, Jun 2, 2019 at 4:51 PM Michael Ring wrote: > I tried answering a question on the list today and to do so I did my > 'first time ever' compile of the avr target. > > This is how I tried to build the avr-embedded target on my Mac: > >SUBARCH=avr5; BINUTILSPREFIX=avr- ; CROSSOPT="-O-

Re: [fpc-devel] FPC AVR embedded

On Thu, Apr 18, 2019 at 4:40 PM Florian Klämpfl wrote: > Am 18. April 2019 12:07:33 schrieb "Dimitrios Chr. Ioannidis via > fpc-devel" : > > > Hi, > > > > I'll appreciate if you can tell me if the AVR target will continue to > > be supported. Is there a maintainer for this target ? > > Define

Re: [fpc-devel] Competing patches

On Sun, 21 Apr 2019, 04:50 J. Gareth Moreton, wrote: > Hi everyone, > > Recently I decided to take up issue #34772 because, of all things, I was > offered a bounty to fix it! I successfully fixed the bug, but another > developer, seeing that I had assigned the issue to mysef, posted their own >

[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

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=" >

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. &g

[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

[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

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

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,

[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.

[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

[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 (

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 ? > > ( > >

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

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:

[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

[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

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_TARG

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 schrie

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 di

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.

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 e

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..2

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

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

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

[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

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

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 e

[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

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

[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

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: > >

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

[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).

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

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

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 al

[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

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

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

[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,

Re: [fpc-devel] ConsoleIO and flushing buffered output

O 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 2

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 >

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.

Re: [fpc-devel] ConsoleIO and flushing buffered output

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

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

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 li

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

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

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

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: >

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

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

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 >&

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: > >

Re: [fpc-devel] Proposal for implementing named address space support

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

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

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,

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@lis

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 te

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

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

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 >> informatio

[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,

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

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 prepar

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 relative

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

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 A

[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

  1   2   >