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
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
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
ested 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
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
enerate 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
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
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/uni
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
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/f
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
.
Best regards,
Christo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
hould 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
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:
> >
/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
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
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
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).
>
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
.
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
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 ?
>
> (
>
>
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
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="
>
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
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,
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
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
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/ccrau
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
1 - 100 of 153 matches
Mail list logo
