Re: [fpc-devel] Save the current FPC UnicodeString!
I see that this should not be discussed here :) . Thanks ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
I did not yet try or consider to use the GUI part of MSEGUJI, as my intention is about doing embedded stuff (e.g. with NoGUIApplication). So sorry for may ignorance about this seemingly already thoroughly discussed issue. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Installing fpc-2.4.0-0.rc1.src.rpm to OpenSuse 11.2
On Mon, 2009-11-16 at 00:26 +0200, Juha Manninen wrote: Hi, I installed FPC 2.4.0 rc1 from rpm packages for OpenSuse 11.2. I can't install the source package fpc-2.4.0-0.rc1.src.rpm though. rpm -i fpc-2.4.0-0.rc1.src.rpm or rpm -i --force fpc-2.4.0-0.rc1.src.rpm give a warning about user joost and group joost missing and tells it uses root instead. It is a warning, not error, but still the files are not installed. The graphical rpm tools give an error but no explanation for it. Do anyone else have such problems? Well, I think the package is normally installed. But this package contains the sources to compile the package itself. Normally you don't need it. The package contains only two files: fpc-2.4.0rc1-src.tar.gz and fpc-2.4.0rc1.spec. It is installed in the packages-source dir of your system. On Fedora it is: /usr/src/REDHAT/... I think SuSe has another place for them. That it is using my own name, well.. it shoudn't. But I think it has nothing to do with the %files section (as it is the source-rpm). I'll build it as fakeroot next time. Binary package fpc-2.4.0-0.rc1.i386.rpm installed fine after ignoring a dependency for libtinfo.so.5. It seems to affect the text IDE only, not the compiler and so is not a problem. Hmm. I thought it would add no dependencies to the package. I'll look if I can fix this. One more thing. Page http://www.freepascal.org/develop.var has tells how to get latest development version of FPC from SVN. However it does not tell how to compile it. ./compiler/README.txt tells to read programmers manual which is not included. Now I am running make all at the source root dir. It is compiling already a long time. Is it the right way? Yes. Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
Michael Schnell wrote: So MSE-GUI creates it's own Widget set instead of using something like GTK. Is this really advantageous ? Definitely - depending on your needs. That's the whole reason we started fpGUI Toolkit as well. LCL, GTK, etc simply did not do what we needed. In creating our own GUI toolkit, we could implement everything that was required and get same behaviour and look on all supported platforms (another requirement for our projects). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
I see. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Source Code Optimization
Maybe it is something interesting http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf -- Darek ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Could FPC add the PLM based construct?
Hello FPC developers I've been using Algol-like languages since the times of Algol '60. In general I'm rather happy with FPC, but I miss a feature which I found in Intel's PLM languages. I'd like to submit it to see if there's a chance it could be introduced in FPC. The feature is the *based* construct, which makes IMHO typed pointers much easier to deal with. It makes the code easier to write, more readable, and shouldn't break anything existing: it would be a language extension, which, in my incompetent judgment, should be fairly simple to implement. Those who don't like it could just avoid using it, and continue the old way. For those unfamiliar with PLM, the construct in FPC could like that: var Pfoo: pointer; foo: any valid FPC Type based Pfoo; or foo: based Pfoo any valid FPC type; . Pfoo := APointer; foo := Whatever; WhateverElse := foo; This would make Pfoo an untyped pointer, while any occurrence of foo would be replaced by the compiler with a Pfoo^, typed unambiguously by foo type. Multiple declarations are allowed such as: var Pfoo: pointer; Bfoo: byte based Pfoo; Ifoo: Integer based Pfoo; implementation Pfoo := ABytePointer; Bfoo := WhateverByte; Pfoo := AnIntegerPointer; WhateverInteger := Ifoo; This becomes particularly handy when the fpc types more complex, such as different record types. Currently, to achieve the same result you need to write more, without adding to readability and maintainability, but perhaps adding something to obscurity instead: type PByte: ^byte; PInteger: ^Integer; ... var Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; implementation PBfoo := ABytePointer; PBfoo^ := whateverByte; ... PIfoo := AnIntegerPointer; whateverInteger := PIfoo^; Something of the sort is already done with objects or strings where the pointer declaration is implicit. This construct would extend the same logic to all other types, but with an explicit declaration of the pointer. It would, IMHO help to get rid of some of the obscurity inherited by the C language constructs. This would also help to get rid, of the ambiguities (also inherited for C) where a variable name sometimes means the value, sometimes means the pointer, depending on context. Any opinion? -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
Giuliano Colla wrote: var Pfoo: pointer; foo: any valid FPC Type based Pfoo; or foo: based Pfoo any valid FPC type; . Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; I don't see the difference between based and absolute, except order of keywords? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Inconsistency detected in dynamic library
When I execute a small program which links to a dynamic library, ld complains:
cha...@devmachine:/data/test/src/shlib$ ./TestExe
hello 42
Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion
`ns != 0 || i == nloaded' failed!
This is on Debian Lenny (Free Pascal Compiler version 2.2.2
[2008/07/30] for i386
, GNU ld (GNU Binutils for Debian) 2.18.0.20080103). On my Mac the code works.
I do not have much experience with fpc (on linux) and dynamic
libraries and wanted to ask if there is something obvious which I do
wrong. And/or what next steps I should/could do?
(in google I found a similar problem
(http://www.mail-archive.com/fpc-pas...@lists.freepascal.org/msg12444.html)
but it doesn't help me).
The code is below. Thanks for tips and having a look!
Hans-Peter
- TestShlib.pas --
library TestShlib;
{$mode objfpc}{$H+}
uses
SysUtils;
function hello: integer; cdecl;
begin
result:= 42;
end;
exports hello;
begin
end.
- TestExe.pas --
program TestExe;
{$mode objfpc}{$H+}
uses
SysUtils;
function hello: integer; cdecl; external 'TestShlib';
begin
WriteLn( Format( 'hello %d', [hello()] ) );
end.
- compile/link --
fpc -CD TestShlib.pas -o./TestShlib.so
fpc -k-R . -k-lTestShlib TestExe.pas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
Micha Nelissen ha scritto: Giuliano Colla wrote: var Pfoo: pointer; foo: any valid FPC Type based Pfoo; or foo: based Pfoo any valid FPC type; . Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; I don't see the difference between based and absolute, except order of keywords? With based you declare a variable name, which you access directly, without need of an extra type declaration. Pfoo is the pointer, foo is the variable, no ambiguity. With absolute you need a) to declare an extra type (PByte, or whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, then you have ambiguities wether Pfoo means the variable or the pointer. Order of keywords of course is not relevant, I just picked up the first one coming to my mind. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Inconsistency detected in dynamic library
On 16 Nov 2009, at 12:45, Hans-Peter Suter wrote: This is on Debian Lenny (Free Pascal Compiler version 2.2.2 [2008/07/30] for i386 , GNU ld (GNU Binutils for Debian) 2.18.0.20080103). On my Mac the code works. You may want to use at least FPC 2.2.4, several bugs related to dynamic libraries on *nix platforms were fixed there. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
Giuliano Colla wrote: With absolute you need a) to declare an extra type (PByte, or Declaring an extra type is one of those things that make Pascal what it is; declaring before use. whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, So we're talking about saving typing of a '^' ? Explicitly typing a '^' when you're derefencing a pointer makes the code more readable, not less. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
On Mon, 16 Nov 2009 12:17:23 +0100, Micha Nelissen wrote about Re: [fpc-devel] Could FPC add the PLM based construct?: Giuliano Colla wrote: var Pfoo: pointer; foo: any valid FPC Type based Pfoo; or foo: based Pfoo any valid FPC type; . Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; I don't see the difference between based and absolute, except order of keywords? The based keyword actually comes from PL/I, which Intel used as the basis for PL/M. The way based variables work is that they are always accessed via a pointer, but the pointer is always type-neutral. This means that the access to the addressed storage location is determined not by the pointer, but by the based variable (usually a structure). This, in turn, means that one can declare multiple structures associated with just a single pointer, each causing the compiler to generate code specific to that structure. The benefit is that there can be some indicator that tells the application *at run time* what type of structure the pointer is addressing, and the appropriate code to access the data can be executed. The synopsis is that an untyped pointer becomes like a hardware base register, which is the way pointers are meant to be. Note that PL/I also has type-associated pointers, called a handle for the associated type. These behave like Pascal pointers, in that they are rather safer, but far less flexible. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] function RefCount(String) ?
On 16 Nov 2009, at 02:01, Martin wrote: so is their an official way to get hold of the refcount? No, there isn't. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Inconsistency detected in dynamic library
2009/11/16 Jonas Maebe jonas.ma...@elis.ugent.be: You may want to use at least FPC 2.2.4, several bugs related to dynamic libraries on *nix platforms were fixed there. Thanks for your answer! - I updated to FPC 2.2.4 (*) but the inconsistency message is still there. The same happened when I tested on another (VM) machine. pre cha...@devmachine:/data/hs$ fpc -CD TestShlib.pas Free Pascal Compiler version 2.2.4-3 [2009/06/03] for i386 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for i386 Compiling TestShlib.pas Linking libTestShlib.so 11 lines compiled, 0.1 sec cha...@devmachine:/data/hs$ fpc -k-R . -k-lTestShlib TestExe.pas Free Pascal Compiler version 2.2.4-3 [2009/06/03] for i386 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for i386 Compiling TestExe.pas Linking TestExe 8 lines compiled, 0.0 sec cha...@devmachine:/data/hs$ ./TestExe hello 42 Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! /pre Hans-Peter (*) wget http://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20i386%20DEB/Lazarus%200.9.28.2/fpc-2.2.4-3.i386.deb.tar/download ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
Micha Nelissen ha scritto: Giuliano Colla wrote: With absolute you need a) to declare an extra type (PByte, or Declaring an extra type is one of those things that make Pascal what it is; declaring before use. You mean that declaring twice is smarter than declaring just once? You need two declarations: one for the type of the typed pointer, and one for the typed pointer itself. The Pascal type is visible in the pointer type declaration, and not in the pointer declaration (which is in a different section, var vs. type, which in a large program can be quite far away). I hardly see the point. whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, So we're talking about saving typing of a '^' ? Explicitly typing a '^' when you're derefencing a pointer makes the code more readable, not less. You mean that string or object references where pointers are implicitly dereferenced make the code less readable? A MyString^[3] or a MyButton^.Click would be more readable than the current MyString[3] and MyButton.Click? It would be more consistent with the rest of the language, but what I suggest is to push consistency on the opposite direction. -- Giuliano Colla Whenever people agree with me, I always feel I must be wrong (O. Wilde) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Source Code Optimization
Dariusz Mazur wrote: Maybe it is something interesting http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Seems that LLVM doesn't do so well, but not as bad as Microsoft :P. GCC seems to be quite good. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Matej Spiller-Muys wrote on Mon, 16 Nov 2009: I would love fpc to be based on LLVM backend. C bindings are ok, but wouldn't it be better to fix support for cppclass inside fpc (since it is already there) and create more proper C++ headers. C interfacing works today and has been very thoroughly tested. cppclass only works, for very basic things, since 2 days ago or so. Unless someone enjoys debugging a new code generator and a new external language interfacing paradigm at the same time, that does not sound like a very good idea to me. I have studied clang project a bit (as C/C++ frontend for LLVM) and it actually makes more sense to me that FPC compiler even though pascal is generally more readable as a language. CLang SVN: http://llvm.org/svn/llvm-project/cfe/trunk/lib/ (and compare that to FPC compiler source) It doesn't weigh up to over 12 years of experience developing FPC and knowing Object Pascal (to the extent that it's used in the compiler) inside out. My C++ and STL knowledge is basic at best. If someone else wants to create an FPC frontend for LLVM in C++, they are of course free to do so. Another thing is, that I would prefer LLVM backend to be more C++ API compatible than FPC/Delphi even if we loose some FPC features (like RTTI), pascal calling conventions. Then you're no longer talking about porting FPC/Delphi, but about creating a new language inspired by FPC/Delphi. There's nothing wrong with that, but given the amount of bug reports that we already get today when implementation details are slightly different to Delphi's, I'm not sure how much success you'd have with the existing Delphi/FPC users. You have to offer a basic amount of either compatibility or incredible advantages before anyone will want to use your compiler. As soon as the hurdle gets too high, many people will simply not consider it worth it and stick to what they know. The threshold is different for different people, but it's not that high in general. Basically I don't think FPC should just go into LLVM direction, but should support LLVM efforts to create more pluggable backends. FPC's backend is already quite plugable (otherwise we would not be able to have 6 codegenerators maintained by 3-4 people). It's just at a lower level currently than what something like LLVM requires. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
C interfacing works today and has been very thoroughly tested. cppclass only works, for very basic things, since 2 days ago or so. Unless someone enjoys debugging a new code generator and a new external language interfacing paradigm at the same time, that does not sound like a very good idea to me. Absolutely you have a point here. But AFAIK C++ linking is part of FPC roadmap (not part of LLVM discussion at all). And LLVM C++ support is at least currently more feature complete. Finish porting LLVM to C or supporting C++. The question is what is more maintainable in the end? It doesn't weigh up to over 12 years of experience developing FPC and knowing Object Pascal (to the extent that it's used in the compiler) inside out. My C++ and STL knowledge is basic at best. If someone else wants to create an FPC frontend for LLVM in C++, they are of course free to do so. Exactly, I prefer frontend in FPC too, reusing lexer, parser, AST. Using LLVM only as a compiled library for codegen (with C or C++ bindings). Then you're no longer talking about porting FPC/Delphi, but about creating a new language inspired by FPC/Delphi. There's nothing wrong with that, but given the amount of bug reports that we already get today when implementation details are slightly different to Delphi's, I'm not sure how much success you'd have with the existing Delphi/FPC users. Actually I am. I was talking about C++ ABI ( not API, that was typo :) ). Having class VMT, exceptions the same as C++ could be a huge interop benefit :) And you get the C++ linking for free. Currently LLVM is still quite evolving. And it would be easier to start with code based on CLang (with some FPC features missing) and later add more FPC features when other projects invent features that C++ does not have (VMKit Reflection,RTTI). It should be the faster way to implement LLVM frontend. With currently implemented clang we could already support 90% of FPC language. You have to offer a basic amount of either compatibility or incredible advantages before anyone will want to use your compiler. As soon as the hurdle gets too high, many people will simply not consider it worth it and stick to what they know. The threshold is different for different people, but it's not that high in general. True. And supporting LLVM does indeed offer a lot of incredible advantages (well not all of them right away). FPC's backend is already quite plugable (otherwise we would not be able to have 6 codegenerators maintained by 3-4 people). It's just at a lower level currently than what something like LLVM requires. That's what I meant. Abstraction on higher level. http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Btw how does FPC or Delphi fare in comparison to LLVM, GCC, VC++? Matej Spiller-Muys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Matej Spiller-Muys wrote on Mon, 16 Nov 2009: C interfacing works today and has been very thoroughly tested. cppclass only works, for very basic things, since 2 days ago or so. Unless someone enjoys debugging a new code generator and a new external language interfacing paradigm at the same time, that does not sound like a very good idea to me. Absolutely you have a point here. But AFAIK C++ linking is part of FPC roadmap (not part of LLVM discussion at all). There is no real FPC roadmap (the website page on future plans is just some random things that people picked up on the mailing lists, or that someone at one point intended to work on). There are only things that people submit/commit patches for. Currently, someone appears to be interesting in adding such support, so it may well be implemented in the future. Or maybe he loses interest and starts working on something else instead, and then it may not be. And LLVM C++ support is at least currently more feature complete. Finish porting LLVM to C or supporting C++. The question is what is more maintainable in the end? No, the question is what do people submit patches for. Having class VMT, exceptions the same as C++ could be a huge interop benefit :) And you get the C++ linking for free. You also get breaking backwards compatibility with a lot of existing Delphi code for free. I repeat: you really cannot underestimate the amount of implementation details that existing Delphi code depends on, and people already complain about FPC's incompatibility with those implementation details. Currently LLVM is still quite evolving. So is FPC. And it would be easier to start with code based on CLang (with some FPC features missing) and later add more FPC features when other projects invent features that C++ does not have (VMKit Reflection,RTTI). It should be the faster way to implement LLVM frontend. With currently implemented clang we could already support 90% of FPC language. So what is holding you back? Really, trying to convince other people to do something that you would like to see done (or even worse: to work on it in the way that you would prefer them to do it) in general just doesn't work. The only way to achieve your projects is to start working on them yourself, and hope that other people join in. http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Btw how does FPC or Delphi fare in comparison to LLVM, GCC, VC++? I have no idea. All I know that's slightly related is the alioth computer language benchmark game (with the stress on game), where you have at least both FPC and GCC results. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
You also get breaking backwards compatibility with a lot of existing Delphi code for free. I repeat: you really cannot underestimate the amount of implementation details that existing Delphi code depends on, and people already complain about FPC's incompatibility with those implementation details. Just so we are clear, what implementation details are you talking about (that you would loose with C++ ABI)? C++ Builder and Delphi have the same ABI and they work quite nicely together. There are even C++ libraries being used inside delphi (like xerces and xalan). Even Delphi VCL is used inside C++ (Builder). Btw how does the wxForms for Delphi (port of wxWidgets) on Delphi work? It is commercial so I don't know how they have resolved the C++ linking problems because they also claim FPC compatibility. Another possible option is to create a Objective C LLVM wrapper, since FPC already claims to support it. So what is holding you back? Really, trying to convince other people to do something that you would like to see done (or even worse: to work on it in the way that you would prefer them to do it) in general just doesn't work. The only way to achieve your projects is to start working on them yourself, and hope that other people join in. Currently I am still working into getting more complete COM support into FPC (0014919) and a lot is already in SVN. What is holding me back is crashing of applications using FPC DLLs (0014861 and 0014807). I could help LLVM efforts, but couldn't really lead a LLVM port, due to lack of time. But nevertheless debating how each developer see the benefits of each solution is still good IMHO (no matter what direction the development will actually take). Maybe i'll start next on more complete support for C++. Because I need xerces/xalan and it uses only virtual functions inside C++ (so it should be simple to port). Or just create OO for libxml/libxslt or start effort to implement native FPC xslt. No, the question is what do people submit patches for. True, but more readable code helps :) I tried to resolve above bugs myself by studying FPC compiler a bit, even working on cleaner FPCDoc parser (0011240), but fpc compiler is just too complex and confusing (for the available time that I currently have :) ). I have no idea. All I know that's slightly related is the alioth computer language benchmark game (with the stress on game), where you have at least both FPC and GCC results. Yup, the FPC factor is 2x-10x slower. http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=fpascallang2=gppbox=1 LLVM that is currently 30% slower than GCC and could speed FPC quite a bit :). Matej Spiller-Muys ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
On 17 Nov 2009, at 07:31, Matej Spiller-Muys wrote: I have no idea. All I know that's slightly related is the alioth computer language benchmark game (with the stress on game), where you have at least both FPC and GCC results. Yup, the FPC factor is 2x-10x slower. That's because you are looking at x86_64 results for FPC 2.2.2, which does not support register variables on x86_64. The i386 results are 20% slower than G++ on average. And as mentioned before, it's with the stress on game: the results on that site depend on almost as much on the implementation effort that people have put in optimizing the source code for their language as it does on the compiler. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Jonas Maebe schreef: On 17 Nov 2009, at 07:31, Matej Spiller-Muys wrote: I have no idea. All I know that's slightly related is the alioth computer language benchmark game (with the stress on game), where you have at least both FPC and GCC results. Yup, the FPC factor is 2x-10x slower. That's because you are looking at x86_64 results for FPC 2.2.2, which does not support register variables on x86_64. The i386 results are 20% slower than G++ on average. And as mentioned before, it's with the stress on game: the results on that site depend on almost as much on the implementation effort that people have put in optimizing the source code for their language as it does on the compiler. And: If you look at CPU secs, then the factor is 3 at most. What helps the C++ programs most is that they use 4 cores more, the fpc programs are mostly singlethreaded. LLVM doesn't help to solve this (AFAIK). Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
On 17 Nov 2009, at 08:18, Vincent Snijders wrote: Jonas Maebe schreef: And as mentioned before, it's with the stress on game: the results on that site depend on almost as much on the implementation effort that people have put in optimizing the source code for their language as it does on the compiler. And: If you look at CPU secs, then the factor is 3 at most. What helps the C++ programs most is that they use 4 cores more, the fpc programs are mostly singlethreaded. LLVM doesn't help to solve this (AFAIK). I don't think that LLVM contains an auto paralleliser at this time (not for SIMD, nor for multiple threads). Anyway, the above is an example of what I mentioned earlier (in the quoted text at the top of this message), since it's of course perfectly possible to also write multi-threaded versions using FPC. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
