Re: [fpc-devel] FPC and Z80

Am 27.04.2020 um 17:52 schrieb Karoly Balogh (Charlie/SGR): Hi, On Mon, 27 Apr 2020, Sven Barth via fpc-devel wrote: Well, I'm surprised and impressed you got it to work at all... Quite an achievement. Considering that we already support AVR as well I was rather confident here. :D Maybe in

Re: [fpc-devel] FPC and Z80

Am 27.04.2020 um 15:37 schrieb nickysn--- via fpc-devel: On Mon, 2020-04-20 at 17:07 +0300, nick...@gmail.com wrote: On Thu, 2020-04-16 at 11:04 +0200, Guillermo wrote: Thanks Swen. I see last commit was 2 days ago so it is active. I would like to know who is responsible to speak to him. May

Re: [fpc-devel] New feature announcement: constant parameters for generics

Am 26.04.2020 um 11:02 schrieb Michael Van Canneyt: On Sun, 26 Apr 2020, Ryan Joseph via fpc-devel wrote: On Apr 26, 2020, at 2:38 PM, Michael Van Canneyt wrote: As the original author, can you say something about the intended use of this feature ? It was meant for a pretty narrow

Re: [fpc-devel] What is the best match for for -mfpu=fpv4-sp-d16 on fpc-arm?

Am 11.04.2020 um 21:03 schrieb Michael Ring via fpc-devel: I have now set up new target freertos-arm and want to start playing arround with freertos. I have compiled freertos with STM32CubeIDE, only 'problem' is that I need to compile with floting point enabled, with Soft-Float the build

Re: [fpc-devel] Recent changes to x86-64 peephole optimisation

Am 08.03.2020 um 15:54 schrieb J. Gareth Moreton: Hi everyone, I've been away for a few days so I haven't been paying too much attention to the trunk, but I've noticed some new changes to the x86- 64 peephole optimized that look interesting. Can someone fill me in on what they're meant to do

Re: [fpc-devel] Question about NOP instructions

Am 02.11.2019 um 15:08 schrieb J. Gareth Moreton: > Hi everyone, > > During my optimisation travels, I frequently stumble across lone NOP > instructions in the compiled assembly language.  Normally I leave these > alone, but occasionally I stumble across things like this: > >     ... >     movq  

Re: [fpc-devel] Guidance for code generation for shift operations for AVR target

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.  The AVR processor doesn't have a barrel shifter, > instead it can only shift a single bit

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Am 06.07.2019 um 17:38 schrieb Sven Barth via fpc-devel: >> I tried to follow the thread, but one think I miss is: what are the >> rules for indention? Does the lines string contain >> spaces at the beginning of every line or not? Are they removed? How >> many are removed? What about tabs?

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Am 28.06.2019 um 11:24 schrieb George Bakhtadze: This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen and FPC's LLVM backend the assumption is incorrect which can be seen by them having added "volatile" mechanisms. I believe this assumption incorrect because

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am 25.10.2018 um 09:06 schrieb Sven Barth via fpc-devel: Simon Kissel > schrieb am Do., 25. Okt. 2018, 08:54: - Complete the LLVM branch of FPC. It looks like Jonas has stopped   working on it two years ago, which is a pity. I personally don't

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am 25.10.2018 um 11:18 schrieb Sven Barth via fpc-devel: Michael Van Canneyt > schrieb am Do., 25. Okt. 2018, 09:38: On Sat, 20 Oct 2018, Simon Kissel wrote: > - Make Exception handling, TLS etc use the infrastructure that >  libpthread is

Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

Am 25.10.2018 um 17:38 schrieb Karoly Balogh (Charlie/SGR): Hi, On Thu, 25 Oct 2018, Michael Van Canneyt wrote: - Make Exception handling, TLS etc use the infrastructure that libpthread is providing TLS is handled already by libpthread. I doubt you will gain much there. GCC has

Re: [fpc-devel] Pure function Wiki page

Am 09.07.2018 um 18:24 schrieb Max Nazhalov via fpc-devel: Just one question: doesn't all this new stuff introduce another kind of mess during cross-compiling? E.g. some complex nested const.expr. "sin(cos(0.12345))" evaluated by the compiler on x64 (double precision) is not the same as if it

Re: [fpc-devel] Maximum symbol length -- answer needed

Am 01.07.2018 um 20:49 schrieb Jonas Maebe: > On 01/07/18 20:27, Florian Klaempfl wrote: >> Am 23.06.2018 um 10:48 schrieb Jonas Maebe: >>> I doubt this is a major contributor to that fact (especially since >>> implicit exception frames are disabled for the compiler

Re: [fpc-devel] Maximum symbol length -- answer needed

Am 23.06.2018 um 10:48 schrieb Jonas Maebe: >> Personally, if I had any stake in this, I would be against it. I mean, >> FPC is already slower than DCC. > > I doubt this is a major contributor to that fact (especially since > implicit exception frames are disabled for the compiler binary, so >

Re: [fpc-devel] "ease of use" patches

Am 18.05.2018 um 02:01 schrieb J. Gareth Moreton: Hi everyone, I've just recently submitted a patch with some code that makes one of the compiler errors clearer for the user, and minimises a 'cascade' where more errors appear due to the presence of the first one. Translations aside, what's

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

Am 28.04.2018 um 17:57 schrieb Thorsten Engler: >> -Original Message- >> From: fpc-devel On Behalf >> Of Florian Klämpfl >> So something like >> >> cmp edx, $4330 >> jge @@zero >> cmp edx, $3FE0 >> .align 16 >>

Re: [fpc-devel] Multiple variable initialization

Am 24.03.2018 um 20:21 schrieb Ondrej Pokorny: > > Anyway, my favorite example of non-pascalish syntax within FPC are the > +=, -= etc. operators. I really don't understand how they made it into > FPC if so many FPC developers are stubbornly against simple and helpful > extensions :) The were

Re: [fpc-devel] Multiple variable initialization

Am 24.03.2018 um 11:46 schrieb Ondrej Pokorny: > Is there a reason why multiple variable initialization is forbidden? > > program Test; > var >   A: Integer = 0;    // allowed >   B, C: Integer = 0; // not allowed > begin > end. > > Will a patch be applied that allows it? As the first one is

Re: [fpc-devel] trunk broken

Am 02.09.2017 um 17:06 schrieb Karoly Balogh (Charlie/SGR): > Hi, > > On Sat, 2 Sep 2017, Marco van de Voort wrote: > >> The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it >> defines an array with texpropcode as range. >> >> This prohibits building of trunk. > > Sven

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 21:08 schrieb Ondrej Pokorny: > On 16.07.2017 20:42, Florian Klämpfl wrote: >> "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid >> opcode (memory dump written). >> Why? Because it does not range check before entering the jump table. > > OK, I confess I am not a

Re: [fpc-devel] UTF-8 string literals

Am 05.05.2017 um 13:53 schrieb Mattias Gaertner: > Hi, > > AFAIK FPC stores UTF-8 string literals (-Fcutf8) -Fc tells the compiler only the encoding of the source code page, it says nothing how string constant shall be encoded. > as widestrings > instead of UTF8String. Please correct me if I'm

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

Am 01.05.2017 um 11:36 schrieb Michael Van Canneyt: > > > On Mon, 1 May 2017, Nikolai Zhubr wrote: > >> 01.05.2017 11:46, Florian Klämpfl: >> [...] And I'm still getting just an address anyway... >>> >>> >>> 3.0.x is broken in this regard (stack back trace on x86-64 elf targets), >> see

Re: [fpc-devel] Management operators AddRef and Copy vs Copy

Am 25.04.2016 um 16:47 schrieb Maciej Izak: > Finally I've decided to use Clone and Copy (as proposed by Florian). Glad to hear :) Another thing: I wonder if those really need to be operators? In C++, "clone" is also only a special constructor. > Should I adjust RTL inner functions to this? I

Re: [fpc-devel] fpc iso mode

Am 03.02.2016 um 22:38 schrieb Sven Barth: > On 03.02.2016 20:07, Tomas Hajny wrote: >> On Wed, February 3, 2016 20:00, Sven Barth wrote: >>> On 03.02.2016 16:58, Schindler Karl-Michael wrote: >> . >> . How about his suggestion about renaming the mode to iso7185? Too late? >>> >>> We could

Re: [fpc-devel] Specific RTL for embedded target

Am 20.11.2015 um 23:57 schrieb Simon Ameis: >> > So will FPC provide the compiler (and maybe an FPC-embedded linker for > ARM) only? > Or would be a reasonable goal to publish "default" device drivers for > embedded targets? > As Marco said: if somebody contributes patches, they are probably

Re: [fpc-devel] FPC 3.0.0-rc2 release

Am 21.10.2015 um 14:48 schrieb Max Nazhalov: > > I doubt it ever had been working.. (that glitch I've seen and > forgotten in a hurry some years ago) > > Example [i386-win32 target]: > var > a, b: array [0..111] of byte; // some arbitrarily not-so-large entities > begin > a := b; > end. > >

Re: [fpc-devel] FPC 3.0.0-rc1 release

Am 26.08.2015 um 08:45 schrieb Marco van de Voort: In our previous episode, LacaK said: i386, x86_64, PowerPC or Sparc processor Win32: - MS Windows NT/2000/2003/XP/Vista/7 (Win95, 98 and ME are not supported in FPC officially any longer). But here is Win95,98,Me explicitly excluded. I

Re: [fpc-devel] avr port, feedback to changes until 30549

Am 12.04.2015 um 01:50 schrieb Georg Hieber: Florian, presently the make cycle aborts when compiling the compiler. In cgcpu.pas there ist a comment (code not working yet), line 770, inside a comment which causes an error. Fixed in r30554. after fixing that, both the compiler and the rtl

Re: [fpc-devel] RTTI interface variant late binding issue (mORMot)

I'll create a branch and commit the supplied patches so far, we can use this branch to bring things into a reasonable shape. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Bug or Feature? Inline of code from Units does not work when types uses in code are defined in implementation

Am 06.04.2015 um 17:53 schrieb Michael Ring: Take the following unit, my goal is to have the code called in the unit inlined in the main code. This works fine when type pLongWord = ^LongWord; is defined in the interface of the unit. if this is defined in Implementation then

Re: [fpc-devel] What means -Oodfa ?

Am 22.03.2015 um 15:53 schrieb Juha Manninen: There are some false positive warnings. Trunk or fixes? For example this construct can be found in Lazarus IDE code frequently. function IDEDirectiveNameToDirective(const DirectiveName: string): TIDEDirective; begin for

Re: [fpc-devel] Future of FPCUP tool

Am 21.02.2015 11:17, schrieb Marco van de Voort: In our previous episode, Juha Manninen said: rare that new people are interested to improve a tool, it should not be ignored. Should it be under FPC sources? If there is a motivated maintainer from outside, can he get commit access for it?

Re: [fpc-devel] CMem allocator memory alignment experiment

Am 19.11.2014 12:32, schrieb Karoly Balogh (Charlie/SGR): Hi, On Wed, 19 Nov 2014, Jonas Maebe wrote: Since the RTL's allocator is documented to align to 16 bytes Where? Ok, that's actually a very good question. :) I didn't find it anywhere, except some earlier ML/forum posts revealed

Re: [fpc-devel] Building of FPC trunk broken on Darwin

Am 23.11.2014 16:50, schrieb Jonas Maebe: On 23/11/14 16:31, Joao Morais wrote: Trunk is broken on Darwin i386 since rev 29085 with the following message: = /Applications/Xcode.app/Contents/Developer/usr/bin/make echotime Start now 13:25:24 /usr/bin/diff ppc3 ppc386 Binary files

Re: [fpc-devel] Masm

Am 07.11.2014 10:35, schrieb Adriaan van Os: Anybody with hands-on experience compiling with FPC for MASM, including the RTL ? The FPC compiler option is there. NASM ist probably supported better and should be able to generate a lot of different object file types.

Re: [fpc-devel] Build packages 2.6.4 on arm/linux failed

Am 28.03.2014 21:36, schrieb Marc Weustink: Hi, I was playing with GNUroot/debian on my android pad and installed fpc 2.6.0 since 2.6.4 was not available. After that I tried to build 2.6.4 from svn. However make all stopped when building fastcgi: /usr/bin/make -C fastcgi all make[1]:

Re: [fpc-devel] FPC and Windows Phone 8

Just a note: trunk supports now to generate hardfloat arithmetics with thumb enabled. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC and Windows Phone 8

Am 19.03.2014 15:10, schrieb Vsevolod Alekseyev: With -CpARMv7M, I presume? Thanks, I'll try. Yes. What kind of thumb is generated depends on the -Cp switch. On 3/19/2014 9:42 AM, Florian Klaempfl wrote: Just a note: trunk supports now to generate hardfloat arithmetics with thumb enabled

Re: [fpc-devel] Issue 0025028 (Florian)

Am 20.02.2014 02:58, schrieb Flávio Etrusco: If Delphi indeed behaves like that then maybe it's valid RFE for Delphi mode. OTOH automatically generating a GUID defeats a few features of having a stable GUID. And even if fpc could avoid modifying the GUID on every modification inside the unit by

[fpc-devel] Test, please ignore

___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Optimizations

(c) 1993-2012 by Florian Klaempfl and others Target OS: Win32 for i386 Compiling sha256.pp Linking sha256.exe 74 lines compiled, 0.1 sec , 26016 bytes code, 2220 bytes data fptime sha256 Expected: 3994057095, got 3994057095 483.000 ms pp -n @c:\fpc\bin\fpc.cfg -l -O4 sha256.pp -S2 Free Pascal

Re: [fpc-devel] Test, please ignore

Am 25.01.2014 17:06, schrieb Florian Klaempfl: Sorry, I forgot to setup up cleaning up backups so the mailing list server ran out of disk space. So it stopped working, it should be back again. ___ fpc-devel maillist - fpc-devel

Re: [fpc-devel] More peephole

Am 23.01.2014 21:15, schrieb Martin Frb: On 23/01/2014 20:04, Florian Klämpfl wrote: Am 23.01.2014 20:52, schrieb Martin Frb: On 23/01/2014 19:35, Florian Klämpfl wrote: I think this is hard to achive as well. Why? I consider it as complicated and it covers only cases one can forsee. Some

Re: [fpc-devel] Little feature teaser

Am 03.08.2013 23:31, schrieb Sven Barth: On 03.08.2013 22:50, Florian Klämpfl wrote: Am 03.08.2013 17:19, schrieb Sven Barth: On 03.08.2013 13:12, Florian Klämpfl wrote: First, FPC does not loop unrolling by default, you need -Ooloopunroll, second, the loop is relatively long, so let the

Re: [fpc-devel] Bug: Alignment issue with dwarf debug_info on mipsel(-embedded)?? code

Can anybody help with a fix? Do I understand it correctly, that it is sufficient so replace .long by .4byte and .short by .2byte at all locations? Does it apply to all targets? Please tell me if r25054 helps. ___ fpc-devel maillist -

Re: [fpc-devel] FPC SoftFPU implementation

Am 12.06.2013 15:45, schrieb Max Nazhalov: Wednesday, June 12, 2013, 4:00:52 AM, Florian wrote: FK Am 09.06.2013 18:22, schrieb Max Nazhalov: Could this patch be reviewed and accepted/adapted/rejected? FK Thanks, I applied it and fixed a few more things. Thanks a lot! Just two addition

Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

Am 06.03.2013 14:16, schrieb Martin Schreiber: On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3 A last one, simple MSEgui demo, one form, a fancy

Re: [fpc-devel] [patch] Mantis issue 9961

Am 10.03.2013 18:53, schrieb Aleksa Todorovic: Hi, FPC developers! I've commited patch to issue 9961 few days ago, and I'd like to ask if someone could take a look at it? I'm currently analyzing several other unit-loading issues (10551, 18294) with similar situations (relative paths, different

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Am 06.03.2013 11:12, schrieb Michael Schnell: So (as with all x86 variants) no library or system call is necessary. Wrong. This is not true in the general case, please read the appropriate api documents. With Cortex, this has changed to the use of the CP15 Register (freeing A9 to allow

Re: [fpc-devel] Delphi anonymous methods

Am 05.03.2013 11:10, schrieb Paul Ishenin: 05.03.13, 17:55, Sven Barth wrote: @Paul: see? :) I see you, Graeme, Michael and probably some more 5-6 developers. Even if those are the only ones, from the beginning, FPC tried to support all niches. And if someone maintaines a certain niche,

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Am 02.03.2013 13:24, schrieb Marco van de Voort: In our previous episode, Florian Kl?mpfl said: (for example renaming all files to .pp takes off +/- 1 second here) Nevertheless, I'd be interested in seeing the strace. Better parallize the building using some build units. Then it will be

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Am 02.03.2013 15:15, schrieb Craig Peterson: On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt mich...@freepascal.org wrote: If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, because you don't see it from the outside, of course he will be finished

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Am 02.03.2013 16:23, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) In theory yes but I still fear

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Am 02.03.2013 17:24, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: I don't see why there would be more synchronization overhead than make? In a parallelized compiler symtables etc. might be shared and this might require a lot of synchronization to prevent data

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Am 02.03.2013 16:49, schrieb Michael Van Canneyt: All this said: You will not hear me claiming that there is no room for improvement in FPC. I'm sure there is. However, I do not think we'll be able to match Delphi's speed without sacrificing the main goal of FPC: to support as much platforms as

Re: [fpc-devel] Refr Bruhl

Am 22.02.2013 15:36, schrieb Refr Bruhl: http://wwwp2t Please do not click the link in this mail, it is probably malware/spam. I have set the moderation flag for Refr Bruhl. Sorry for any inconvenience caused by this. ___ fpc-devel maillist

Re: [fpc-devel] Summer of code collaboration

Am 10.02.2013 15:23, schrieb Vittorio Giovara: Indeed, a fpc-js code generator would have a rather limited use. A LLVM backend instead could be use on many more levels, and for example could improve (or replace) the compilation process on iOS. Improve in which regard? Experience showed that

Re: [fpc-devel] Summer of code collaboration

Am 10.02.2013 15:23, schrieb Vittorio Giovara: Indeed, a fpc-js code generator would have a rather limited use. A LLVM backend instead could be use on many more levels, and for example Not to mention that I estimate that full llvm support with debugging and extending llvm to support

Re: [fpc-devel] Forwarded message about FPC status

Am 25.12.2012 12:38, schrieb Michael Van Canneyt: On Tue, 25 Dec 2012, Martin Schreiber wrote: On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote: Everybody is aware of the speed difference between Delphi and FPC. The compiling itself (parsing/producing assembler code) is not

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 14:53, schrieb Jy V: Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It

Re: [fpc-devel] Forwarded message about FPC status

Am 25.12.2012 14:44, schrieb Jy V: The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. Is this close i386 intermediate code similar to IR LLVM generation ? No. It must be much

Re: [fpc-devel] Forwarded message about FPC status

Am 25.12.2012 15:04, schrieb Sven Barth: On 25.12.2012 14:15, Florian Klaempfl wrote: The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. Ewww... please not... No, we would be back in pre 1.0

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 14:59, schrieb Yury Sidorov: From: Yury Sidorov j...@cp-lab.com From: Florian Klaempfl flor...@freepascal.org Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 15:11, schrieb Paul Ishenin: 25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 15:17, schrieb Yury Sidorov: From: Paul Ishenin paul.ishe...@gmail.com 25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe

Re: [fpc-devel] Forwarded message about FPC status

Am 25.12.2012 19:30, schrieb Dimitri Smits: I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the compiler on windows was at least a few minutes. It is windows: self compilation. No rtl building or whatever. The only approach I see to

Re: [fpc-devel] Forwarded message about FPC statusy

Am 25.12.2012 19:39, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 18:01:50 +0100 Florian Klaempfl flor...@freepascal.org wrote: Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names

Re: [fpc-devel] Re: FPC related fairy tale

Am 18.10.2012 22:16, schrieb Sven Barth: On 18.10.2012 13:13, Sven Barth wrote: Over the past weeks I've spent some time on getting something to work in FPC and now I'm about to commit this either this evening or at least this weekend (depending on the time I have). I've now commited my

Re: [fpc-devel] stellaris launchpad

Am 16.09.2012 17:53, schrieb Daniël Mantione: Op Sun, 16 Sep 2012, schreef Luca Olivetti: but I don't know the outcome. Is it currently possible to develop software for that mcu with freepascal? As far as I know the Cortex M series cannot run generic ARM code; it only understands the

Re: [fpc-devel] FPC compiler architecture documentation

Am 31.08.2012 09:32, schrieb Michael Schnell: On 08/30/2012 10:20 PM, Florian Klaempfl wrote: I doubt that a good developer needs such a document to get into the compiler... Hmmm. I once thought about trying to do an fpc compiler for a not yet supported arch, and I still am interested

Re: [fpc-devel] FPC compiler architecture documentation

Am 30.08.2012 13:42, schrieb Marco van de Voort: In our previous episode, Graeme Geldenhuys said: I found this old PDF documenting the FPC compiler architecture. I remember in recent years others attempted to do a similar thing. I don't know how accurate this PDF still is, considering it is

Re: [fpc-devel] Does FPC optimize unused parameters ?

Am 24.08.2012 13:48, schrieb Jonas Maebe: Martin wrote on Fri, 24 Aug 2012: On 24/08/2012 12:04, Jonas Maebe wrote: Martin wrote on Fri, 24 Aug 2012: The above takes the first of the overloaded. All bodies are empty. procedure DebugLn(const s: string = ''); inline; overload; That looks

Re: [fpc-devel] about freepascal for mips

Am 25.05.2012 21:04, schrieb Jeppe Græsdal Johansen: I managed to remove the errors with the following patch, such that everything compiled, but I haven't been able to test it: http://j-software.dk/fpc-mipsel.patch All fixes of the patch are committed, I solved some things differently

Re: [fpc-devel] about freepascal for mips

And the whole code seems totally incompatible with standard mips abi, it use 6 registers to pass parameters, while o32 has 4. cpupara needs a major overhaul. This is one of the next things I planned to do. ___ fpc-devel maillist -

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

Am 11.03.2012 12:01, schrieb peter green: It appears to me (i'm not an expert on arm assembler and I can't seem to find any documentation on FPA) that FPC is generating FPA instructions even though the FPU is set to a VFP type. What i'm really struggling to work out is why the heck that is

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

Am 11.03.2012 13:22, schrieb Jonas Maebe: * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. But isn't this caused by the fact that we have the same executable name while it

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

Am 11.03.2012 15:37, schrieb Jonas Maebe: On 11 Mar 2012, at 15:14, Florian Klaempfl wrote: Am 11.03.2012 13:22, schrieb Jonas Maebe: * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion

Re: [fpc-devel] Bounty for MIPS

Am 03.02.2012 01:37, schrieb Nikolai Zhubr: Hi, 31.01.2012 0:08, Pierre Free Pascal: Anyhow, I just discovered that the /home directory is 99% full on that GCC compile farm machine, meaning that only remote tests will be possible ☹ It seems that lots of developers have the same issue about

Re: [fpc-devel] Pointer cache for fast class/pointer access.

Am 21.01.2012 14:25, schrieb Sven Barth: On 20.01.2012 11:18, Skybuck Flying wrote: Finally if you do believe prefetching is a good alternative to a pointer cache or simply want to try out the effect of prefetching class pointers then I challenge you to implement it in a experimental branch of

Re: [fpc-devel] Stack alignment on i386

Am 22.12.2011 17:56, schrieb Jonas Maebe: Keeping an aligned stack requires completely different code generation inside the calling routine, you can't implement that on a call-by-call basis. Intel defined once how procedure entry/exit code should look like for procedures doing 16 byte

Re: [fpc-devel] rounding precision error with integer and floating point division

Am 17.11.2011 20:51, schrieb Seth Grover: Although I can avoid the problem by casting the longword to a double How should the compiler know that the division should be done using double? Using always double slows down calculations. Because the range of longword fits into a single as well as

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

Am 22.09.2011 11:51, schrieb Henry Vermaak: On 22 September 2011 10:26, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk wrote: I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then have moved it between local machines as a binary. I can confirm that 2.4.4 will build

Re: [fpc-devel] Issue 20124: Error with static direct field properties

Am 01.09.2011 17:48, schrieb Alexander Klenin: [Is there any method to either comment on or re-open resolved isses? It is very frustrating to be forced to switch comminication channel] I think this issue is resolved prematurely. First, I do not see a reason why normal property can not be

Re: [fpc-devel] Const optimization is a serious bug

Am 07.07.2011 08:35, schrieb Alexander Klenin: As further support for #1, consider: With a class, you do not have to pass it to a procedure as var, but when you modify the instance, you modify the same instance as was passed to the procedure. That is how classes work. Having a variable point

Re: [fpc-devel] Const optimization is a serious bug

Am 04.07.2011 22:39, schrieb Chad Berchek: I've been reading over some of the recent discussion about reference counting problems with const string parameters. I've done some experiments and I believe that the so-called const optimization is a serious flaw, not just a corner case of

Re: [fpc-devel] MIPS

Am 30.05.2011 10:58, schrieb Marco van de Voort: So one would really need a cut down RTL for this. That's why we have the feature switches. Though I admit that it hard to use for the outer rtl and packages because it would require a lot of ifdef'ing thus polluting the sources.

Re: [fpc-devel] Comparison FPC 2.4.4 - Delphi 7

Am 30.05.2011 13:21, schrieb Mattias Gaertner: Do you know, how much is compiling and how much is linking? Linking time is little: [10.205] Linking mseidefpc.exe [10.767] 310695 lines compiled, 10.8 sec , 2277216 bytes code, 1703496 bytes data [10.768] 148 warning(s) issued So approx.

Re: [fpc-devel] Macro Processing

Am 16.05.2011 02:30, schrieb Joerg Schuelke: Am Sun, 15 May 2011 13:26:03 +0200 (CEST) schrieb Daniël Mantione daniel.manti...@freepascal.org: Feel free to come up with examples and convince us. They need to be examples of code that is much more awkward to write without macro's. We

Re: [fpc-devel] Macro Processing

Am 14.05.2011 15:07, schrieb Joerg Schuelke: Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpflflor...@freepascal.org: Because a lot of code in the compiler is very old (remember, it was started in 1993 using TP) and writestr for enums is new compare with this time span. Nobody rewrote

Re: [fpc-devel] Macro Processing

I could live with something similiar you proposed, maybe with other preprocessor keywords like $macro and $expand instead so that it's clear it's something new. But I fear this is not what most people being pro macro want: they want something like C and think this will solve all the C header

Re: [fpc-devel] Macro Processing

Am 13.05.2011 13:45, schrieb Joerg Schuelke: Am Fri, 13 May 2011 11:47:54 +0200 schrieb Florian Klaempfl flor...@freepascal.org: procedure dp(const x : string;y : array of const);inline; begin dbgstr(x,y); end; Nothing is wrong with that. Except: - the code will never vanish

Re: [fpc-devel] Macro Processing

Am 13.05.2011 14:28, schrieb Joerg Schuelke: Am Fri, 13 May 2011 14:05:43 +0200 schrieb Florian Klaempfl flor...@freepascal.org: Extending dump_stack is imo a much better approach, it even doesn't duplicated information already available in debugging info. Thats a unit? I`m a small man

Re: [fpc-devel] Declare variables inside the code

Am 11.05.2011 14:52, schrieb Jonas Maebe: but I'm personally not missing anything as far as compiler development is concerned. Me neither. And if I really need output during compilation, I add the needed code manually like printnode(self); to get a node tree at a particular place. Having

Re: [fpc-devel] Default IntToStr operator for '+' symbol.

Am 29.04.2011 10:23, schrieb Felipe Monteiro de Carvalho: The Pascal way to avoid using too much IntToStr is: begin s := Format('%d %d', [X, Y]); end; Much shorter, no? ... or writestr(s,x,' ',y); ___ fpc-devel maillist -

Re: [fpc-devel] type pointer to record before record.

Am 29.04.2011 15:51, schrieb Flávio Etrusco: type TMyRecord = record mPrev : ^TMyRecord; // not allowed. end; Marco, only if you happen to know from the top of your head, would it be possible and without consequences to allow this kind of construction? (i.e. a pointer reference to

Re: [fpc-devel] {$I %LINE%} and friends

Am 29.04.2011 10:59, schrieb Hans-Peter Diettrich: michael.vancann...@wisa.be schrieb: But what is the cleaner way? To defer the expansion of {$I %xxx%} inside macros, or to define c-like macros __LINE__ and __FILE__, maybe with nicer names? Defer expansion. The use of {$I } is mandatory,

Re: [fpc-devel] fpc modifiers

Am 29.04.2011 00:02, schrieb Joerg Schuelke: Am Thu, 28 Apr 2011 23:39:35 +0200 schrieb Hans-Peter Diettrichdrdiettri...@aol.com: The bug resides in the dirty Delphi OPL definition. Is it a bug or unspecified behavior? I think it is implemented in the hope it works good enough. If you

  1   2   3   4   5   6   7   8   9   10   >