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 > 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 FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk. > > I got 2.4.4 here: > > ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/ > > Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without > problems. Toshiba AC100 is armel (arm eabi) while fpc arm-linux (arm oabi)? While this might work under certain circumstances, I wouldn't bet on it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 24, fpc uses a single division. > point before the division, this seems like it should be done > automatically to make results across architectures consistent. This is not possible. Especially i386/x87 behaves really strange because it does calculations always with extended. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 alignment by themself. Of course, main problem is, this requires another register on i386. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 the >> free pascal compiler, so the prefetch idea can be tried out and tested ! > > Why don't you try yourself whether it has a positive effect? "prefetch" > is already part of FPC's RTL since quite some time: > http://www.freepascal.org/docs-html/rtl/system/prefetch.html ... and the compiler itself uses it already for several years. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 finding MIPS machines for testing …. >>> >>> Would you consider the NetGear WNDR3800 680Mhz, 128MB RAM with a USB >>> Flash drive of 32GB to be good enough for the development of the FPC >>> toolchain ? >>> (in this case, I can purchase and ship such device to your place), >>> >>> or would you consider that only a qemu virtual MIPS machine which can >>> handle more memory and more disk space to be suitable for the >>> development ? >> >>I just googled a bit and read that the >> USB flash drives are considered as having only a limited number of writes >> before that fail... (http://en.wikipedia.org/wiki/USB_flash_drive) >> So I wonder how long such a system like that would last (it probably >> also depends on >> the USB key quality itself?) if I run the testsuite each night >> on it... >> >> Would a small USB hard drive be better? But does the device >> have enough power to support such an external drive? >> Would the speed be significantly lower or is the USB 2.0 >> speed the real limitation? > > Ok. Debian installer ran amazingly smooth and apparently debian is quite > happy with openwrt's kernel. How did you install debian? Or is it a chroot'ed debian? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 happening. From telling > freepascal to include source lines as comments in the assembler it > doesn't look like inline assembler is responsible. Can you please post the full assembler listing of a procedure containing such code? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 generates different code? I currently think that having even arm/armeb/armel/armhf as cpu types is the way to go. This allows also to have units for all four flavours on one system. Currently we simply don't support the same target cpu but different abi in any way in the build system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 as it is with ppcarm variants. >> >> But isn't this caused by the fact that we have the same executable >> name while it generates different code? > > Yes. > >> I currently think that having even arm/armeb/armel/armhf as cpu >> types is the way to go. This allows also to have units for all four >> flavours on one system. Currently we simply don't support the same >> target cpu but different abi in any way in the build system. > > We also don't support an RTL compiled with -Cp386, -Cppentium, > -Cppentium2, -Cppentium2, -Cppentiumm, -Cfx86, -Cfsse2 and/or -Cfsse3 > on the same system. True, but they are not different abis, debian does not treat them different either. > For ARM hard float, you will also need different > sets of units depending on the exact kind of VFP cpu you have (unless > you always target the lowest common denominator -- if something like > that even exists for all VFP variants, since ARM is not that big on > backward compatibility and they have their own standard of encoding > the entire ABI, target cpu and all other details into attributes > inside every generated object file so that the linker can verify the > compatibility). But the abi stays on all hard float platforms the same? Indenpendent of the instruction set. > > Whether it's ABI or minimally required target cpu, the part that > causes the trouble is that you need a different set of units. I don't > think that renaming the compiler binary just for this particular case > is the right approach. Since the same compiler executable cannot run on the other platforms, I think naming them differently is reasonable. In general, I'd take the debian architecture scheme as measure. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Float to string conversion performance
Am 15.04.2012 17:03, schrieb Max Nazhalov: Anyway, I ran that diff on the same conditions as above. Full test suite did not show any regressions. This is already a good sign. My test case resulted in: "1.2345678901234568E+3999": FPC=1.92 seconds "1.2345678901234568E-3999": FPC=1.83 seconds so its timing is still about 2.5 times slower than Delphi, but much better then before. Can anyone review or test suggested changes before creating Mantis entry? I guess nobody can competely oversee such changes to real2str so what about creating automatically a test program which converts a lot of random bit patters into strings by str(...) and compare the output of the old and new algorithm? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 13:44, schrieb Martin Schreiber: On Sunday 22 July 2012 13:23:50 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: I don't think it's the best. I'm also quite sure it will require more work from you in the long run, keeping them up to date and merging bug fixes and new features from FPC back into your fork. I doubt it, the experience shows the opposite. :-) AFAIK TObject is the only class which depends on compiler magic? Are there other classes which can not be duplicated? Pretty much anything in the system and dialect units (objpas, macpas, objc, iso7185) is/can be(come) tightly bound to the compiler. The rest should be safe. So classes.pp except for TObject is safe? Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. Ah, yes. So whole classes unit is independent from compiler. Super. :-) I wouldn't bet on it though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
Am 22.07.2012 14:06, schrieb Martin Schreiber: On Sunday 22 July 2012 13:53:28 Florian Klaempfl wrote: So classes.pp except for TObject is safe? Afaik yes. Exception is in sysutils (magic too ?), tobject is in objpas. Ah, yes. So whole classes unit is independent from compiler. Super. :-) I wouldn't bet on it though. Why not? There is no guarantee. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 like a very serious bug introduced in the handling of parameters to inlined routines. Florian changed several things there over the last couple of months, maybe he has an idea. Yes, r21445 is guilty. para.left should be checked with might_have_sideeffects if refs=0 if it really could be removed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 based on FPC v1.x, Not really I think. I converted it from the original word document to latex/pdf. The source is in fpcdocs/internal directory http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/internal/?root=docs Still waiting for sb to actualize it. While it still might an interesting reading for somebody not involved in the compiler development I doubt it's usefulness. It requires a lot of work of some of the compiler developers but I doubt that a good developer needs such a document to get into the compiler so updating the document is wasted time in the sense of bringing the compiler forward. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 in having (AKA contributing to such an effort) an "up to date" fpc compiler for as well 68K as PIC32 (AFAIK identical to a certain version of MIPS32). I doubt that I would even be able to start, unless an up-to-date documentation of the appropriate parts of the docu is available. The big picture which could be documented is the easy part. But such a document can never cover all details and the details are the hairy part. Like certain properties of the target architecture might be special and not yet covered by the compiler thus they cannot be documented. They are the challenging and time consuming part when adding a new architecture. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 Thumb2 instruction set. FPC supports Thumb-2 code generation and arm-embedded supports also some stellaris types (LM3S* types) so it should be possible with little effort to compile programs with FPC for this device. But maybe Jeppe can say more. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 changes, but currently the compiler for m68k can only be build from within an IDE (e.g. Lazarus) as the makefile immediately complains that "ppcross68k" is missing if I want to start a "make cycle CPU_TARGET=m68k" (or a "make all CPU_TARGET=m68k"). It works for other CPUs though... (besides the point that FPC currently can't cycle on a i386-linux...) Does anyone know what the problem could be for m68k? Wrong naming somewhere in the makefile? Anyways, here it stops with c:/fpc/svn/compiler/ppc.exe -Ur -Xs -O2 -n -Fum68k -Fusystems -Fuc:/fpc/svn/rtl/units/i386-win32 -Fi m68k -FE. -FUm68k/units/i386-win32 -dRELEASE-dm68k -dGDB -dBROWSERLOG -dNOOPT -Sew pp.pas cpupara.pas(52,90) Error: Identifier not found "tcpuregisterset" cpupara.pas(52,20) Error: There is no method in an ancestor class to be overridden: "procedure get_v olatile_registers_int(tproccalloption):;" cpupara.pas(59,3) Fatal: There were 2 errors compiling module, stopping ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 slow. From what I remember, the problems you (and everyone else) experience with smartlinking and so on are largely due to the GNU linker being slow and memory hungry. AFAIK there are significant differences in parsing and code producing too. I suggest that Florian answers this, he has more exact numbers. I see no way to speed up the 2.x FPC significantly only by stripping something down or whatever. The whole 2.x design is geared towards portability and maintainability, speed is only 2nd level goal (and being honest, self compilation in ~10 sec even on my >5 year old Core 2 Duo is not that bad ;)). 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 25.12.2012 11:32, schrieb Mark Morgan Lloyd: Michael Van Canneyt wrote: On Mon, 24 Dec 2012, Martin Schreiber wrote: - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. You know that sacrifices need to be made to make a compiler cross platform and easily portable. You can't have it all. We will see. It would be good if, prior to forking off, you would do some study and post some proposals here. As long as your proposals do not include reducing the number of platforms/CPUs (an obvious optimization), I'm sure they will get serious consideration: Although I think the time is approaching when some CPUs- IA-64 etc.- and OSes could usefully be moved into an "attic" subtree. What's the advantage in doing so? The code hangs around and does not hurt in any way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. I do agree, you should consider his position. The total time FPC spend in memory manangement is 20% iirc. So I don't see much optimization potential here. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 closer to i386 else there is no speed advantage over the current approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 times :) Not to mention the fact that writing such a backend probably takes one year of work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 14:59, schrieb Yury Sidorov: From: "Yury Sidorov" From: "Florian Klaempfl" 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 handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... Still zero-filling a million of small memory chunks is very time consuming. It is better to pre-zerofill big pool blocks first and then assueme that memory already zero fillled in custom object init code. 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 is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. 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% :( Ops, messages crossed :) I'd expect no more. One thing might be to rewrite the whole unit handling so that symtables etc. can be read/written as one block to PPUs but doing so might be also pretty time consuming and I doubt the maintainability of such an approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 still much better than nothing. Yes, but you might also pay with a higher memory footprint which might even eat this speed advantage under certain circumstances. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
Am 25.12.2012 15:17, schrieb Yury Sidorov: From: "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 still much better than nothing. Sure, but I would be happy to expect at least 2X increase :) In such case I would start coding the fix right now :) Believe me, if it was so easy, I would have it done for years ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. This would allow to keep the many features of fpc. I had a setup where I compiled zeos with FPC and Delphi (which doesn't link), and iirc the results were also 7-10times, with delphi XE. When I'm home after Christmas I'll play a bit and see if I can duplicate the experiments with Delphi XE3. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. lovely, but isn't that what Embarcadero is doing for their future compiler? No. It is exactly the counterpart. llvm intermediate language is for sure as much as possible platform independent and not "close to i386" as I wrote. If one wants to accelarate FPC by one magnitude one cannot fiddle with some abstract intermediate layer but output already from the parser something as close as possible to i386 machine code, do register allocations and optimizations on it and write the machine code to disk. Using the llvm toolchain, they will provide a front compiler to an intermediate "language" or interpreted code. Then they have a few optimisations for the middle layer and use the back-ends that are already available to make stuff architecturally compile to whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or custom backend) ... and this costs time. And it is similiar to FPC's approach. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 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 (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. Do you mean as separate process? Yes. ppcxyz would be only a front end to this daemon process/service. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Summer of code collaboration
Am 10.02.2013 11:09, schrieb Sven Barth: Having a LLVM backend would not only benefit HedgeWar's JavaScript case, but also all others that would like to use the LLVM backend for one purpose or the other. And in my opinion a pure JS backend would be much harder to implement than a LLVM backend as one also needs to think about how certain things should be implemented in JS (which the emscripten developers already thought of). Well, I doubt that this will work smoothless but since I don't care about js or llvm support I won't argue about it :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 the more tools involved the less comfortable the use of FPC is. Within a few minutes you can build on any platform a win32 cross compiler (if the CPU is fast enough) because no external tools are involved. Compare this with cross compiling to linux (no to talk about darwin): takes usually 1-2 hours to setup: first, download, configure and build binutils, then sort out the libraries and copy them to host system, and then with some luck (if binutils are not broken), building fpc might work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 everything required by fpc might be more something like 1-2 years of full time work than a few summer months of work of a student. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 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 faster; he didn't perform the same work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. A more apt comparison would be that we hired the painters to paint the outside of the house and one of them did the inside too because his tools require him to paint both sides of the walls. While the other one can paint only in one color and only buildings with one floor ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 that the threadvars and synchronization eats much of the advantage in this case. 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 corruption. With make, the different units can be seperated much better by a human than the compiler can do. Not to mention the huge effort it would be to get the compiler parallelized internally. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 corruption. With make, the different units can be seperated much better by a human than the compiler can do. Only if you want to avoid multiply used units to be only once in memory. IMHO if you are afraid of that, then don't do that :-) Forking compilers on a by unit level instead of some meta level is typically slower because reading ppus takes a lot of time. Not to mention the huge effort it would be to get the compiler parallelized internally. As said the first step can be relatively simple. Get rid of globals some more, and then only the parts before compile() needs to be changed. In theory, yes. In practice this is a huge effort. Just one example: inlining requires that the node tree of a procedure is copied. However, during copying the tree is annotated for proper copying. Bottom line: even if the compiler finished to compile a unit, the generated info is not read only. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 possible. Well, not to mention the goal of maintainability. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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, the niche will be continued to be support. Actually, I think FPC lives from niches and developers working on niches. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 for better optimization). Now, CP15 is in fact not very suitable for this purpose, as it can only be accessed with privileged instructions and thus not in user mode (where the TLS in fact is invented for).Thus a system call (or trap) is needed to get the address of a threadvar. Wrong. On linux this can be done by a jump to a certain adress. Conclusion: With FPC, the optimization of threadvar access is not necessary. Instead it is highly recommended to always use thread specific instances of the classes that do the threaded work. TThread of course provides this out of the box. And how does one the "current" TThread? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 tlabel, one button: http://mseide-msegui.sourceforge.net/pics/kylix3.png Program size Kylix 3: -rwxr-xr-x 1 mse users 1038420 Mar 6 13:28 kylixdemo FPC 2.6.2, commandline: ppc386 -okylixdemo -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2 -CX -XX -Xs kylixdemo.pas Program size: -rwxr-xr-x 1 mse users 1252204 Mar 6 14:10 kylixdemo Without the used sources it is of very little use. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 unit loading order when compiling and loading ppu), but I'd like to get opinion on solution for issue 9961, if it's possible :) It looked good to me, thanks! I committed it as you might have noticed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 notes: 1. Catched another 4 missing exits Thanks, applied. 2. r24872 seems to revert r24864 by Pierre Muller (see above in mail list) -- was this intended?.. This was a mistake, I fixed it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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 compiler assume a long pipeline with - Cppentium4 -Oopentium4 it is. Are you sure that you don't mean -Oppentium4? The compiler complains with —Oopentium4. And it doesn't change anything (also with -Ooloopunroll) :( There was indeed a mistake in optunroll.pas, -Oppentium4 -Ooloopunroll should work now. Jupp, it indeed works now. Now the compiler would "just" need to detect that the for loop is basically only using constants and evaluate that at compile time... but that's a wish for another day ;) I think item 635365 of my todo list, the autovectorizer would solve it ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
> > - There is only one encoding in MSEgui framework, it is the same on all > platforms. Which is performance wise neither a good decision. > - In the majority of cases the fast and convenient character access by index > can be used. This is important for beginners. > - The current FPC UnicodeString is fast, simple, has little overhead and is > well tested. > > So please don't destroy this ideal solution by dropping current FPC > UnicodeString in favour of the Delphi string which is complicated, Who says that? If you don't mess with code pages, the only different you'll might see is that UnicodeString gets two new fields: encoding and char size. However, this information is usually only used if you pass the string to a RawString parameters. Normal Unicodestring routines initialize these fields and that's it. > less > performant, In which regard? > will have many new bugs and is inscrutable by the average user! > Please remember how many time it took to fix WideString. I don't want to go > this ordeal again. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Martin Schreiber schrieb: > On Tuesday 10 November 2009 12:45:26 Michael Schnell wrote: >> Martin Schreiber wrote: >>> Performance and simplicity. MSEgui does not need the overhead of >>> multi-encoding/multi-charsize. At the moment msestring=UnicodeString for >>> FPC 2.4 which is perfect. I fear FPC will drop this simple solution where >>> it was ahead of Delphi. >> Hmmm. I suppose with Linux (using utf-8 for the GUI interface to the >> user programs), having the user program always use Widestring internally >> and convert any GUI input and output string will feature an enormous >> overhead. >> > Xlib and Xft have an utf-16 interface. Windows has an utf-16 interface. > MSEgui > is faster than Lazarus with Gtk2 and even faster as Lazarus with Gtk1 on > Linux IIRC. > >> I feel that just handling the multi-encoding String-management record >> (with "encoding"6 and "character-size", which, in the case of GUI >> generated and "meant for GUI" Strings, always is equal), would not >> impose much overhead over using using the plain old String management >> with just "reference-counter" and "contents-pointer". >> > Did you look into the code in cpstrnew branch? I did. And which changes are exactly the reason for your concerns? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Martin Schreiber schrieb: > On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote: > >>> Did you look into the code in cpstrnew branch? I did. >> And which changes are exactly the reason for your concerns? > > More checks Where? A pure unicodestring routine won't get additional checks. > and more complicated address calculation. Where? Adding 16 instead of 12 makes no difference. The "major" difference will be the initialization of the additional fields and the increased memory requirement of 4 bytes per string. > OK, you can say "you > will not notice the small difference". But possible this attitude is one of > the reasons that Delphi compiles much faster than FPC? ;-) Yes, and if compilation speed is important for you, you should use delphi ;) What you call "this attitude" is also the reason why FPC can exist: we need always to find a compromise between: - satisfy the needs of as much as possible users - maintainability - portability - performance ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Martin Schreiber schrieb: > On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote: >> Where? A pure unicodestring routine won't get additional checks. >> > What is a "pure unicodestring routine"? No other string types being involved especially things like RawByteString. > >>> and more complicated address calculation. >> Where? Adding 16 instead of 12 makes no difference. >> >> The "major" difference will be the initialization of the additional >> fields and the increased memory requirement of 4 bytes per string. >> > OK, so you say that the processing of the new and the current UnicodeString > and therefore the RTL and compiler procedures are identical with exception of > the initialization of 4 bytes with a constant? Well, two times two byte ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Marco van de Voort schrieb: > In our previous episode, thaddy said: >> Marco van de Voort wrote: >>> While I think it would be best to use native encoding on all platforms as >>> much as possible, that is an opinion. However not using native encoding for >>> general processing is nuts. So we need the UTF8 type anyway. >>> >> Just to make a small point: the choice for UTF16 was made because of >> market reasons, not technical ones. Chinese Korean, Japanese markets are >> important for Delphi. Try to figure out how to fit that in UTF8. Just a >> thought. > > I don't think that is the reason. Codegear/Borland simply followed > Microsoft. Period. It might be a reason for Microsoft though, but that was > made way way long ago, pre 1994-5. MS had no choice: when Windows NT 3.1 was released in 1993, UTF-8 was just about being standardized. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Graeme Geldenhuys schrieb: > Florian Klaempfl wrote: >>> and therefore the RTL and compiler procedures are identical with exception >>> of >>> the initialization of 4 bytes with a constant? >> Well, two times two byte ;) > > I have not looked at the cpstrnew branch, but what is the 4 bytes used > for in each string? Couldn't the individual bits in 1 byte value be > used? That will reduce the extra memory overhead by 75%? The constant encoding the code page requires 2 bytes, element size would require 2 bits only, but alignment issues waste the remaining 14 bit anyways. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Michael Schnell schrieb: > Martin Schreiber wrote: >> OK, so you say that the processing of the new and the current UnicodeString >> and therefore the RTL and compiler procedures are identical with exception >> of >> the initialization of 4 bytes with a constant? Now that is exciting. > > Of course with any operation that uses two strings as an input, the > "encoding and character size" DWord (32 Bits, 24 Bits relevant), needs > to be checked if not equal. But this does not seem like much overhead to me. Only if the string type is RawByteString. E.g. e procedure taking an unicode string as parameter needs no additional checking. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Michael Schnell schrieb: > Florian Klaempfl wrote: >> No other string types being involved especially things like RawByteString. > > If you additionally implement the encoding Type RawWordString, Martin > should be happy. No. RawByteString means simply: encoding unknown, the string is just a couple of bytes (which could also form words or dwords) described by the the encoding and char size fields. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Martin Schreiber schrieb: > On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote: >> Martin Schreiber schrieb: >>> On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote: >>>>> Did you look into the code in cpstrnew branch? I did. >>>> And which changes are exactly the reason for your concerns? >>> More checks >> Where? A pure unicodestring routine won't get additional checks. >> >>> and more complicated address calculation. >> Where? Adding 16 instead of 12 makes no difference. >> >> The "major" difference will be the initialization of the additional >> fields and the increased memory requirement of 4 bytes per string. >> > I try to prove the exciting statement. How can I build a startup compiler for > the cpstrnew branch or I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew branch compiler dir should work using 2.2.4/2.4.0 > how to compile the cpstrnew branch? Since it's a branch, I'am not sure if usual building works. We're still at the point to add new stuff and rework things so it might be heavily broken. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Martin Schreiber schrieb:
> On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote:
>>> I try to prove the exciting statement. How can I build a startup compiler
>>> for the cpstrnew branch or
>> I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew
>> branch compiler dir should work using 2.2.4/2.4.0
>>
> "
> program overhead;
> {$ifdef FPC}{$mode objfpc}{$h+}{$endif}
> {$ifdef mswindows}{$apptype console}{$endif}
> uses
> sysutils;
> var
> str1: unicodestring;
> begin
> str1:= 'abcde';
> end.
> "
>
> Free Pascal Compiler version 2.3.1 [2009/11/11] for i386
> Copyright (c) 1993-2009 by Florian Klaempfl
> Target OS: Linux for i386
> Compiling overhead.pas
> Compiling /home/mse/packs/standard/svn/fp/cpstrnew/rtl/linux/system.pp
> Fatal: Compilation aborted
> An unhandled exception occurred at $FFF4 :
> EAccessViolation : Access violation
> $FFF4
> $0813A594 DO_GENERATE_CODE, line 1432 of psub.pas
> $0813A4D3 READ_PROC_BODY, line 1508 of psub.pas
> $0813A8CA READ_PROC, line 1632 of psub.pas
> $0813ABA1 READ_DECLARATIONS, line 1721 of psub.pas
> $08137884 BLOCK, line 172 of psub.pas
> $08139F4E TCGPROCINFO__PARSE_BODY, line 1318 of psub.pas
> $08186A15 PROC_UNIT, line 1127 of pmodules.pas
> $0816F93D COMPILE, line 394 of parser.pas
> $0817E22C TPPUMODULE__LOADPPU, line 1531 of fppu.pas
> $0818520C ADDUNIT, line 440 of pmodules.pas
> $0818555A LOADDEFAULTUNITS, line 556 of pmodules.pas
> $08188AF7 PROC_PROGRAM, line 2005 of pmodules.pas
> $0816F977 COMPILE, line 402 of parser.pas
> $0806986C COMPILE, line 246 of compiler.pas
> $08048256 main, line 223 of pp.pas
>
> pp.pas compiled with fixes_2_4 by
> "
> /home/mse/packs/standard/svn/fp/fixes_2_4/compiler/ppc386 -opp -Fu./systems/
> -Fi./systems/ -Fl./systems/ -Fo./systems/ -Fu./x86/ -Fi./x86/ -Fl./x86/
> -Fo./x86/ -Fu./i386/ -Fi./i386/ -Fl./i386/ -Fo./i386/ -l -Mobjfpc -Sh
> -dsvnfixes_2_4 -dI386 -gl
> pp.pas
What rtl did you use? You need one from the branch.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Michael Schnell schrieb: > P.S.: > > In this list, we already did discuss doing an FPC version that creates > the intermediate code that can be fed to the GCC code generator. This > would make available to FPC all relevant CPU architectures and > supposedly the low level optimization that gcc4 does on this > intermediate code is hard to beat. Just use GPC then? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Michael Schnell schrieb: > Florian Klaempfl wrote: >> Just use GPC then? > > It does not compile the many thousands of lines of the Delphi project I > want to port :(. Yes, because it's probably very hard to make a (Object) Pascal front end for gcc. Another backend for FPC is 4k-5k lines (pascal, no need to learn C), just make it a bounty for say 2000 Eur and I'am sure, somebody will write you a backend for the desired processor. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
Martin Schreiber schrieb:
> On Tuesday 10 November 2009 10:33:07 Florian Klaempfl wrote:
>>> So please don't destroy this ideal solution by dropping current FPC
>>> UnicodeString in favour of the Delphi string which is complicated,
>> Who says that? If you don't mess with code pages, the only different
>> you'll might see is that UnicodeString gets two new fields: encoding and
>> char size. However, this information is usually only used if you pass
>> the string to a RawString parameters. Normal Unicodestring routines
>> initialize these fields and that's it.
>>
>
> I can confirm there is not much overhead for the new UnicodeString. I was
> mislead by the Delphi {$stringchecks on} option and a misinterpreted comment
> from a FPC developer that it is not possible to check codepage compatibility
> at compiletime, sorry for that.
> Some guesswork gained form my experiments with the cpstrnew branch, Win32,
> Russian locale, source in utf-8, {$codepage utf8}, please correct me if I am
> wrong:
I'am not sure how far these things are already fixed/supposed to work.
>
> What are the differences of AnsiString and RawByteString?
Ansistring: system encoding
RawByteString: variable encoding, cannot be checked at compile time,
when working with RawByteStrings, you've to take care of the newly
introduced encoding field
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
Martin Schreiber schrieb: > On Thursday 12 November 2009 19:26:06 Florian Klaempfl wrote: >>> What are the differences of AnsiString and RawByteString? >> Ansistring: system encoding > > System encoding at compile time or run time? Runtime, as it is currently. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
dmitry boyarintsev schrieb: > On Thu, Nov 12, 2009 at 9:26 PM, Florian Klaempfl > wrote: >> Ansistring: system encoding >> RawByteString: variable encoding, cannot be checked at compile time, >> when working with RawByteStrings, you've to take care of the newly >> introduced encoding field > > Let's say there's a library that works with AnsiString as a string > type with no encoding (as it's now). Well, an ansistring has an implicit encoding: system. This won't change and if one uses only unicodestrings and ansistrings, no change will be noticed. > Let's assume that the new branche is officially accepted. > The library doesn't want the new feature, but it also doesn't want to > change its code from AnsiString to RawByteString. > > Would it be possible to make the following type declaration: > > unit MainLibTypes; > > type > AnsiString = RawByteString; > > to avoid using new auto-converters? No, because it would avoid auto-conversion from/to unicodestring as well. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] First cppclass test
Sven Barth schrieb: >>> If so, how do you >>> suggest to write those tests, especially as they (currently) rely on a >>> external library... >> >> Libraries or object files? FPC does similiar testing for C linking: the >> C sources are checked in into >> http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/ >> Compiled object files lay in the appropriate sub dir of this dir. >> >> Testing C++ class linking should be done similiar imo. >> > > In theory that is possible, but I found a practical problem: C++ code > requires libstdc++ or at least libsupc++ which implements the "new" and > "delete" operators. And to make things worse: this library isn't > available in the Windows release of the compiler... (not a real problem > for me as I'm working on Linux...) A lot name mangling etc. can be tested without new/delete: just make the classes static. Further, fpc must be able to create c++ classes on the heap anyways. > > While I could be able to simulate the needed functionality of the > library through Pascal units with correct named procedures/functions, I > don't think that this is the way to go. A better solution (at least for > compiler tests) would be to just compile but not link those test units. > Does the test framework support such an option? Yes, but this is imo a bad idea, better get it running with some hacking. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
dmitry boyarintsev schrieb: > On Fri, Nov 13, 2009 at 12:44 AM, Florian Klaempfl > wrote: >> Well, an ansistring has an implicit encoding: system. This won't change >> and if one uses only unicodestrings and ansistrings, no change will be >> noticed. > > Thanks. It's always nice to hear "No changes required" :) Well, I guess you're talking about lazarus ;) I don't see yet however, if and how the ansistring abuse in the lcl will bite one ... > >> No, because it would avoid auto-conversion from/to unicodestring as well. > > does your answer means, that: > var > r : RawByteString; > w : WideString; > > r:=w; // is impossible because of unknown encoding of RawByteString? No, it is possible becuase the encoding is known because it is stored in RawByteString, but the appropriate conversion will be selected at runtime. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] understanding generics
Paul Ishenin schrieb: > Hello, FPC developers' list > > I am trying to understand how to add an enumerator support to the fgl > containers. Seems it is imposible. > > I need enumerator to return the same type as generic container. So I > declared enumerator class as generic too. But how to use it inside the > generic container class? > > I guessed to use the next construction: > > generic TFPGList = class(TFPSList) > type public > TFPGListEnumeratorSpec = specialize TFPGListEnumerator; > > > Everything compiles fine, but when I declare a specialize type for the > generic TFPGList I get very strange compiler errors. > > I attached a simple project which exposes the bug. > Probably something wrong with nested token replay. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Graeme Geldenhuys schrieb: > Jonas Maebe wrote: >> Delphi compatibility. And Delphi does that because COM requires this >> behaviour. > > Can't that behaviour be limited to Windows platform only. Now *all* > platforms and all non-COM code has to be stuck with the useless compiler > hint simply because of some Windows and more specifically Windows + COM > behaviour. Without COM, FPC wouldn't have out parameters. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Graeme Geldenhuys schrieb: > Florian Klaempfl wrote: >> Without COM, FPC wouldn't have out parameters. > > Why do you say that? Because I added it for Delphi compatibility which needs it for COM? > I see many use-cases for out parameters You mean for VAROUT parameters :)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Graeme Geldenhuys schrieb: > Florian Klaempfl wrote: >>> I see many use-cases for out parameters >> You mean for VAROUT parameters :)? > > > I search the latest FP Language Reference document, and there is no > mention of 'varout'. I also tried to use varout in a procedure as > follows - which gave a compiler error with FPC 2.4.0-rc1 It is not implemented, but it would be the solution to the fillchar problem. > > procedure dcpFillChar(varout x; count: SizeInt; Value: Byte); overload; > > vs > > procedure dcpFillChar(out x; count: SizeInt; Value: Byte); overload; > > > First one is not compilable, but the second one is. So no, I don't > understand your comment about 'varout'? Please explain more. A VAROUT parameter could have the same semantics as VAR except that the compiler does not expect that it is needed that it is initialized. But be warned: with such a parameter type you can easily create memory leaks with automated types like ansistrings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Vincent Snijders schrieb: > Graeme Geldenhuys schreef: >> Florian Klaempfl wrote: >>>> I see many use-cases for out parameters >>> You mean for VAROUT parameters :)? >> >> >> >> First one is not compilable, but the second one is. So no, I don't >> understand your comment about 'varout'? Please explain more. >> > > varout could be the name of the new parameter modifier that Jonas > mentions[1] and that has the semantics that you think out should have, > but hasn't. The problem with varout is that it easily creates memory leaks with automated types. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Paul Ishenin schrieb:
> Graeme Geldenhuys wrote:
>
>> As I stated in the other mailing list. It's not about a obsession to get
>> hint & warning free code. It's about spoting REAL issues in code between
>> all the crap the compiler currently spits out. If your project uses a
>> lot of structure types, you can quickly sit with thousands of lines of
>> compiler hints like this one. There is no easy way of spotting real hint
>> compared to fake (useless) hints. And I definitely don't have the time
>> to seek through my rather large (200k + LOC projects) projects hint
>> output to try and figure out what is real and what is useless hints.
>
> Then maybe the solution is to add someting like
>
> {$uninitialized_arguments_check_for_functions off}
> procedure FillChar(var ...)
> begin
> ...
> end;
> {$uninitialized_arguments_check_for_functions on}
>
> Compiler will add a flag for each var/const argument that they dont
> require that checks.
This looks really ugly :) Maybe a better solution is to implement a
compiler internal counter part to finalize which simply zeros the
variable and where the compiler knows that the variable must not be
initialized before.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting FPC to a new architecture
Felipe Monteiro de Carvalho schrieb: > On Thu, Nov 19, 2009 at 8:36 AM, Michael Schnell wrote: >> This is great news for me, as I am considering a NIOS2 Port and NIOS2 is >> very similar to MIPS32 so we might be able to work together on this and >> the resulting thingy would support both architectures. > > I already have 2 news about this. > > On the bad side, my potential financer probably won't be able to > finance the project, so I am less commited now. > > On the good site it seams that someone already ported FPC 2.0.0 to > MIPS, but never contributed to the main development: > > http://sourceforge.net/projects/fpc-mips/develop > > Maybe this work could be ported to the latest trunk. > > FPC 2.0.0 is too old for me because I would like to run the latest Lazarus. > Using the above code, a port should be rather easy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Vinzent Höfler schrieb: > Florian Klaempfl : > >> Without COM, FPC wouldn't have out parameters. > > And because there would be no difference between "var" and "out" then, There would be difference: no out keyword at all :) > it also wouldn't have the hint. Case dismissed. ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Vinzent Höfler schrieb: > Florian Klaempfl : > >> A VAROUT parameter could have the same semantics as VAR except that the >> compiler does not expect that it is needed that it is initialized. But >> be warned: with such a parameter type you can easily create memory leaks >> with automated types like ansistrings. > > I don't understand the issue. Indeed, I noticed :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Vinzent Höfler schrieb: > Florian Klaempfl : > >> Vinzent Höfler schrieb: >>> Florian Klaempfl : >>> >>>> A VAROUT parameter could have the same semantics as VAR except that the >>>> compiler does not expect that it is needed that it is initialized. But >>>> be warned: with such a parameter type you can easily create memory >> leaks >>>> with automated types like ansistrings. >>> I don't understand the issue. >> Indeed, I noticed :) > > Care to explain why the programmer can easily determine something which seems > to be an unsolvable problem for the compiler, although both have exactly the > same information? Because a VAROUT parameter would be simply overwritten by the callee even if it contains a valid automated type: procedure p(varout v : ansistring); begin v:='asdf'; end; var s : string; begin s:='asdf'; s:=s+s; p(s); <-- memory leak, s+s is never freed end; OUT does prevent this because s is cleaned up before p is entered. OTOH, OUT causes a crash if s is filled with garbage. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Redefine FillChar() to use out parameter instead
Vinzent Höfler schrieb: > Florian Klaempfl : > >> Because a VAROUT parameter would be simply overwritten by the callee >> even if it contains a valid automated type: > > That's a semantic definition, not an explanation. Sorry, but it seems you didn't follow up the thread, so I won't continue here. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] profiling under windows
Jonas Maebe schrieb: > The only thing that changed in r14137 was adding a prefetch statement > to tgnuassembler.writetree (on i386 you have to compile with > -Cppentium4 or higher for the prefetch statement to do anything > though). Actually pentium3 ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CompareMemrange 64bit
Mattias Gaertner schrieb: > CompareMemRange of unit sysutils takes as Length a cardinal. > > Can this be changed to PtrUInt? > > Same question for CompareMem. > > Should I create a bug report? Bug report with patch ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defines layout for mips
Felipe Monteiro de Carvalho schrieb: > Hello, > > I am wondering about the best way to set the mips target. We are only > targetting mipsel (32-bits, little endian), but the Linux convention > for the name of this target is mipsel, while mips=mipseb, so the > command to build the target should be: > > make all TARGET_OS=linux TARGET_CPU=mipsel > > and in the future someone could possibly use > > make all TARGET_OS=linux TARGET_CPU=mips > > To target the mipseb. > > But looking at the arm port, it doesn't seam to be done this way, > there is a general arm define and other more specific for big endian > and little endian. But maybe arm is different, because in mips eb or > el is very important, you cannot switch the most in software, and > mipsel is the most common. > > I think that the existing defines should be changed from mips to > mipsel, to match the Linux target namming. But I am not sure. Any > comments? As you might have seen, I integrated most of fpc-mips already and I think the way to go is: - mips (compiler target)/cpumips (host) defined for all mips cpus - cpumipsel (host) defined for all mips little endian cpus - cpumipseb (host) defined for all mips big endian cpus - mips32 (compiler target)/cpumips32 (host) defined for all mips 32 bit architectures cpus - mips64 (compiler target)/cpumips32 (host) defined for all mips 64 bit architectures cpus As well as cpumips32el, cpumips32eb, cpumips64el and cpumips64eb. Within the compiler, the eb/el decision is made based on the target_info. The CPU targets makefile wise should be: mips (big endian) mipsel mips64 (big endian) mips64el ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defines layout for mips
Felipe Monteiro de Carvalho schrieb: > Excelent. One thing I don't understand however is the link between the > defines and the makefile targets. > > The Lazarus project for arm uses the -darm option to build a arm > compiler. For mipsel, how would that be? > > -dmipsel ? That doesn't compile. -dmips compiles > > But then I am confused, because I would expect the necessary define to > be -dmipsel and with just -dmips it's not clear that my compiler is > targeting mipsel... The mips integration is not ready yet. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] change default start function in cprt0.o
Jonas Maebe schrieb: > On 04 Dec 2009, at 17:51, Dariusz Mazur wrote: > >> but now another problem >> >> linker say that system.pp need function _haltproc_eabi which is >> absent in ucprt.0 > > That's probably because nobody has maintained the uclibc support > since adding EABI support. The ARM/Linux support is very ad hoc: it > was added, but afaik there is no real maintainer for it (Florian and > I sometimes fix some things, but that's it). uclibc is even less > tested or used. We really need someone who is will to maintain that > platform, I still miss a reasonable EABI development system. > because several people appear to be interested in using it, > but few if any in developing and maintaining the necessary compiler > or RTL support. > > > Jonas___ fpc-devel > maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Idea/question about a language (syntax) extension
Flávio Etrusco schrieb: > But what's your > opinion on extending it to standard procedures? I see no sense in doing so. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dynamic GUI/Console apptype
Mimu Bunnylin schrieb: > So, basically, make a GUI-mode application, let FPC release the console > during its normal startup initialisations, then detect that the parent > process was a console, and recapture the console... This could work, > thanks. It would still seem far simpler to alter the FPC system unit to not > release the console in the first place, but I could not find the relevant > part in the source code. (Too many files, not enough idea of where to > look.) FPC doesn't do the console handling, this is done by windows depending on exectuable flags which are set depending on apptype during linking. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > > If I create a feature request issue for this, does it have any chance of > being > implemented? No. > I think it would be EASY to implement. Then propose a patch. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > On tiistai, 5. tammikuuta 2010 18:07:38 Florian Klaempfl wrote: >> Juha Manninen schrieb: >>> If I create a feature request issue for this, does it have any chance of >>> being implemented? >> No. > > Well thanks, that was a quick answer. According to timestamp you answered my > mail before I sent it! > In this virtual internet reality everything is possible. :-) > > I hope you read my reasoning, too. I knew all the reasoning, but honestly, I don't see a point in it. I used C++ for years professionally and I always avoided circular references/implementing classes in different files than the header is named so I see no need in pascal either (and I never needed it). > I wrote the mail after reading many related > discussions and after being frustrated many times because of this limitation. > So, this was not one of the "me too, I found something to complain" messages > but a real problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: On tiistai, 5. tammikuuta 2010 18:39:21 Florian Klaempfl wrote: I knew all the reasoning, but honestly, I don't see a point in it. I used C++ for years professionally and I always avoided circular references/implementing classes in different files than the header is named so I see no need in pascal either (and I never needed it). Hmmm... In real programs there are classes that are big and are logically their own entities (or how to put it), but still they must refer to other similar classes in other units. I don't know how you have solved this without putting everything into one big file. See e.g. the compiler, but how does a big source file hurt anyways? Today, navigation is done by the IDE and cvs times are also gone when big files were a problem to commit. I consider class reference refering some external files not better than one big file if this is really needed. Things being interwinded can also end in the same file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: On tiistai, 5. tammikuuta 2010 19:16:25 Florian Klaempfl wrote: See e.g. the compiler, but how does a big source file hurt anyways? Today, navigation is done by the IDE and cvs times are also gone when big files were a problem to commit. I consider class reference refering some external files not better than one big file if this is really needed. Things being interwinded can also end in the same file. Ok, that is a good point but then we are talking about a different thing already. Now the question is whether a huge source file is a bad thing or not. IMO, the compiler should not force a programmer to make a 34 000 lines source file (like VirtualTreeView has). I never looked at VirtualTreeView but I doubt that the 34k line source is a language problenm. Programmer should have a choice to split it Good languages prevent programms to do ugly things :) if he wants. Then do the same as in C++ and put it in different include files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: > On 05 Jan 2010, at 17:45, Juha Manninen wrote: > >> On tiistai, 5. tammikuuta 2010 18:14:53 Jonas Maebe wrote: >>> The reason that they are conceptually not the same thing is that >>> in Pascal two different units can both declare a different class >>> with the same name (just like they can both have global variables >>> and procedures/functions in the interface with the same name). >>> You would at least have to do something like one of the following >>> a) use one global name space for all classes (i.e., forbid that >>> two different units used in a program declare a class with the >>> same name anywhere), or b) add some way to specify the unit name >>> in which this external class is specified, or >>> >>> There might be other solutions (maybe some kind of class-specific >>> namespace support), but it would definitely require some more >>> language features rather than merely accepting anonymous class >>> definitions anywhere. Otherwise the type checking is going to run >>> completely haywire. >> Yes, I even suggested a syntax: TMyClass = class; defined in >> "MyUnit.pas" > > You're right, sorry. > >> which would solve the namespace issue. It is the case b) you >> listed. It could also be: MyUnit.TMyClass = class; >> >> which is similar than syntax referencing global variables from >> another unit. > > It would have at least two consequences (there are undoubtedly more > that I'm not thinking of currently): a) all forward-declared types > from the interface would have to be resolved after the uses-clause in > the implementation has been parsed (because only at that point all > classes would be known) b) this would cause the interface crc of > those units to change (since the types change once they are > resolved), which means that every unit containing such a construct > (and every unit depending on them, even if they don't touch these > types) would be recompiled at least once (some immediately in case of > circular interface-implementation unit references, some only when you > recompile the project) > > This wouldn't double the compilation time, but it would probably slow > down things quite a bit. I'm also not sure whether the ppu > storing/logic logic would still work if it could be called at a point > where not all forward-declared types are resolved. It would probably > require special code for that situation. Defining forward types in a different unit breaks completly with the spirit how object pascal is designed and I fear it will break much more stuff in the compiler. Changing interface CRCs are probably only one of the prominent problems. Resolving cyclic forward class references between units will be probably a real nightmare. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Graeme Geldenhuys schrieb: > On 05/01/2010, Martin Sucha wrote: >> You should be able to achieve that by putting some ifdefs around interface >> and >> implementation (and other) parts of your autogenerated programs and then for >> example > > True and I have done this before. BIG problem is that class visibility > goes out the window! All classes can access ALL private and protected > field variables or methods of other classes. NOT GOOD! That's why we've strict private/protected. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Graeme Geldenhuys schrieb: > 2010/1/6 Vincent Snijders : >> You are getting old: >> http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg13343.html > > Ah, but that would explain why I don't use it. I never develop in > delphi mode, only objfpc mode - unless I work with projects like tiOPF > where both compilers (Delphi and FPC) are requirements. > Does my sentence exclude that strict works in fpc mode too. iirc it is supposed to work in all modes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Nikolai ZHUBR schrieb: > Tuesday, January 05, 2010, 11:08:37 PM, Juha Manninen wrote: >> On tiistai, 5. tammikuuta 2010 20:06:42 Florian Klaempfl wrote: >>> Then do the same as in C++ and put it in different include files. > >> Right, include files could solve this problem at least partly. They seem to >> be > > Curious enough, nobody even mentioned interfaced objects (interfaces), > though they are available in both FPC and Delphi since ages. > Indeed, there are multiple ways to prevent the hell of circular class references between units: - abstract base classes - interfases - include files - big units - type casting (in the worst case) - ... The right choice depends on the application. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > Still, best solution has been to put everything into one big file. And still, > I don't like that compiler forces such a thing. The compiler forces you many other things. Still, I don't get what's the problem with a large unit if it's really needed (and nothing like abstract base classes or interfaces or type casts or ... helps). Stuff closely depending on each other should end in the same unit. You even cannot test a unit with external circular class references without the other involved units. So why should the stuff be separated? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Michael Schnell schrieb: > Stefan Kisdaroczi wrote: > >> to create hard realtime linux programs with freepascal and xenomai [1] in >> userspace > > Ooops > > Userspace means Linux and Linux means no hard realtime possible (with > the official definition of hard realtime: reaching a predefined timing > deadline with 100% certainty). Did you look at the xenomai website? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schrieb: > Juha Manninen schrieb: >> Still, best solution has been to put everything into one big file. And >> still, >> I don't like that compiler forces such a thing. > > The compiler forces you many other things. Still, I don't get what's the > problem with a large unit if it's really needed (and nothing like > abstract base classes or interfaces or type casts or ... helps). Stuff > closely depending on each other should end in the same unit. You even > cannot test a unit with external circular class references without the > other involved units. So why should the stuff be separated? Add: FPC can also smartlink large units so no need to split stuff into thousands of object files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: > In our previous episode, Florian Klaempfl said: >>> Still, best solution has been to put everything into one big file. And >>> still, >>> I don't like that compiler forces such a thing. >> The compiler forces you many other things. Still, I don't get what's the >> problem with a large unit if it's really needed (and nothing like >> abstract base classes or interfaces or type casts or ... helps). Stuff >> closely depending on each other should end in the same unit. You even >> cannot test a unit with external circular class references without the >> other involved units. So why should the stuff be separated? > > I don't like extremely large (> few thousand lines) units from an overview > perspective. One can also say a lot of small files make it hard to find stuff (remember the people to complain about the huge amount of files of the fpc rtl :)?). With a good ide you don't care about this anymore: it works the same with a lot of small files or one huge file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: >> (remember the people to complain about the huge amount of files of the >> fpc rtl :)?). > > The point is that they are right from a birds-eye general application > development view. I wanted only to point out that there pros and cons for small/large units and if a design requires to put a lot of stuff into one unit becuase it is heavily interwinded, I see no problem with it. > But wrong from the perspective of the exact requirements > on the RTL. IOW the RTL is not a normal piece of code. > >> With a good ide you don't care about this anymore: it works the same with >> a lot of small files or one huge file. > > Then I never saw a good IDE. With lazarus you don't notive in which files the code actually is? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Florian Klaempfl schrieb: > Marco van de Voort schrieb: >>> (remember the people to complain about the huge amount of files of the >>> fpc rtl :)?). >> The point is that they are right from a birds-eye general application >> development view. > > I wanted only to point out that there pros and cons for small/large > units and if a design requires to put a lot of stuff into one unit > becuase it is heavily interwinded, I see no problem with it. ... and splitting the unit by external circular class types makes no use, it even makes things less readable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Juha Manninen schrieb: > > Other programming languages have different cultures. See the comment from my > original post in this thread. It was from a professional programmer and I > understand it. Some development teams want to put every class into its own > file. Different languages, different habits. I even consider putting every class in its own header and implementation file as a bad habit. There is no reason to do anymore because modern C/C++ compiler can smartlink on a sub-object level which they could not for years. > C and C++ even have headers in separate files (which is messy IMO). > > So, if a professional team chooses a programming language / environment for a > project, this one feature can make a strong point against Object Pascal. Then they are not eduacated well enough because they don't know the reason why C++ programmers put (past tense) every class into it's own object file. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] custom ThreadManager and MemoryMutexManager for hard realtime
Michael Schnell schrieb: > Florian Klaempfl wrote: > >> Did you look at the xenomai website? > > Seemingly you need to do your own device drivers and not use any Linux > system calls in your realtime process, that seems to run Linux in a kind > of virtualization. Hard real time causes a lot of limitation, indeed. > > So FPC programming for realtime would require to prevent FPC from > creating Linux system calls. Thus you need a modified RTL (e.g. for > memory management). Guess why the topic of this thread is "custom ThreadManager and MemoryMutexManager" ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: > > On 06 Jan 2010, at 12:14, Florian Klaempfl wrote: > >> Different languages, different habits. I even consider putting every >> class in its own header and implementation file as a bad habit. There is >> no reason to do anymore because modern C/C++ compiler can smartlink on a >> sub-object level which they could not for years. > > Another reason is probably to speed up the compilation: > * (re)compiling huge source files can be slow and/or require lots of > memory, depending on the used compiler (and debug information or > optimization settings) For single class c++ files, imo most of the time is spent into reading the huge headers which are often even not needed and a complete mess because nobody has an overview which classes are used and which not. > * every separate C/C++ file can be compiled in parallel with all others That's might be a point. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Jonas Maebe schrieb: > > On 06 Jan 2010, at 13:04, Florian Klaempfl wrote: > >> Jonas Maebe schrieb: >>> >>> Another reason is probably to speed up the compilation: >>> * (re)compiling huge source files can be slow and/or require lots of >>> memory, depending on the used compiler (and debug information or >>> optimization settings) >> >> For single class c++ files, imo most of the time is spent into reading >> the huge headers which are often even not needed and a complete mess >> because nobody has an overview which classes are used and which not. > > It depends. Since these compilers only see whatever is in the current > source file (and its header files), putting more code in the same source > file can significantly slow down interprocedural optimizations (as soon > as one algorithm with quadratic complexity is involved). And inlining > can significantly increase the complexity of single routines as well, > making stuff such as register allocation much slower :) On the other hand keeping things in different files avoids these optimizations. And being honest: I think using a debug switch set without any optimization and with maximum checks and fast compilation should be used for developer builds while wpo, inlining etc. is switched on during relese builds. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort schrieb: > In our previous episode, Wimpie Nortje said: >> Did you have a look at AVR? > > Yes, but from what I remember it was canceled because the amount of > periphery on the chip is poor. I also looked at ARM, but while there is more > choice there, it is fragmented over multiple vendors, with multiple > toolchains (if a free one exists at all) Of course ;) Called FPC :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
