On Tue, Sep 17, 2024 at 10:38 AM Marģers . via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> There is release_3_2_4-branch with fpc version 3.2.4-rc1. As i understand
> this is foundation for fpc 3.2.4 release!
> Is there possible to add more commits from main branch? I know that fixes is
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
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
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 b
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
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 ite
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.f
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 call
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 G
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
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 dire
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 genera
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 with
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 f
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
IsMemoryManag
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 ow
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
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
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 f
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 e
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
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 s
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 a
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 co
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
65aebd22b0cb4e1709648
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
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 som
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, w
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> wr
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
>> informati
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 wa
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, MIPSE
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
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 f
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 PPU
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
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 =
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:
> >
lve 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
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). Accessi
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:
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
FPC=~/fpc/3.3.1/compiler/p
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 ju
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 release,
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 pos
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
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 to c
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, 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. On
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, he
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/itx86
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
understa
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 f
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-b
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/Mak
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.
>
> Sin
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
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 ever
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 exis
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
&g
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://li
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 fol
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 ?
>
> (
>
> https://www.microchip.com/webdoc/avrlibcreferencemanual/using_tools_1using_
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/
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
failure
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/listin
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 (longb
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 targe
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
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
defaul
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.
Th
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 ( At
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); i
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 n
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
1 - 100 of 127 matches
Mail list logo