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
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
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
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
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
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
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
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
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
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
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
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
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 w
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?
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
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
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
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.fr
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
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
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
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
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
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
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
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
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
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
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
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,
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>
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
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
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
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,
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
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
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
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
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:
>
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
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
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
>&
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
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:
> >
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
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).
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
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:
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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.
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,
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
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
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
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
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:
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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 ?
>
> (
>
>
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 (
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
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
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
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
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="
>
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
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,
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.
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 (
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);
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
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
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
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
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-
1 - 100 of 124 matches
Mail list logo