Re: [fpc-pascal] making fpc
Bobby Walters schrieb: > Hello, > > I downloaded teh fpc sources on my Intel Itanium 2. iA-64 isn't supported by FPC. > I types sudo make > and it gave me the following, what should i do?: To bootstrap fpc, you need already an fpc :) > > make: -iVSPTPSOTO: Command not found > make: -iSP: Command not found > make: -iTP: Command not found > make: -iSO: Command not found > make: -iTO: Command not found > > Targets > all Alias for build > build Build a new compiler and all packages > install Install newly build files > zipinstall Create zip/tar of installed files > singlezipinstall Alias for zipinstall > > Distribution Targets: > rpm Build linux .rpm packages > deb Build linux .deb packages > inno Build Windows (Innosetup) based installer > tar Build .tar installer > > FV based installer Targets: > go32v2zip Build .zip files for go32v2 > os2zip Build .zip files for OS/2 > sourcezip Build .zip files for the sources > > > > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Am 29.04.2012 11:40, schrieb ik: > Hello, > > Here is something that I'm asking without really know anything about > the subject, so please bear with me. > > I'ved asked few places that works with Pascal (Delphi and FPC), why > does they use C as the infrastructure, and they all say that there is > not even one Pascal compiler that makes the code optimized and fast > running with low resources, while many C compilers does have such > features. > For them it's not the language, but the compilers that are problematic. > > I'm not talking about "killer feature" that never exists, but what > stops FPC and/or other Pascal compilers to be more optimized, with > lower footprint, Regarding footprint, FPC is far ahead of everything: http://shootout.alioth.debian.org/u32/which-language-is-best.php?calc=chart&gpp=on&java=on&ghc=on&sbcl=on&csharp=on&racket=on&v8=on&hipe=on&vw=on&php=on&python3=on&lua=on&perl=on&yarv=on&cint=on&xfullcpu=0&xmem=1&xloc=0&nbody=1&fannkuchredux=1&meteor=0&fasta=1&fastaredux=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1®exdna=1&pidigits=1&chameneosredux=0&threadring=0&binarytrees=1 > faster code like with C compilers for example ? Spent more man power into optimizer development, though some optimizations are hard in pascal because we assume stricter aliasing rules and because we don't have a volatile keyword. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
On 29 Apr 2012, at 12:22, Florian Klämpfl wrote: > Spent more man power into optimizer development, though some > optimizations are hard in pascal because we assume stricter aliasing > rules and because we don't have a volatile keyword. At least as far as our current optimizers are concerned, nothing is volatile in Pascal: both the assembler and node tree optimizers will replace multiple loads of global data with a single load when they can. So that should not limit any optimizations at this time. Regarding aliasing, I'm not sure whether C defines anything regarding that. You at least need to use the -fstrict-aliasing gcc flag to tell it to assume that pointers to different types cannot alias each other (and hence get better optimizations). In standard Pascal, pointers by definition can only point to data of one particular type, so it could be compiled with -fstrict-aliasing in any case. Since in FPC/Delphi this is no longer the case, you could introduce a similar switch there to allow programmers to tell the compiler that their code also obeys strict aliasing rules. In general, I think it's indeed simply a matter of the amount of man power spent on optimizations. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
What would be usefull is to move the loads of code stored in sysutils/runtime into a dll/so. thats what makes C code look "smaller", theres a nice libc (and others) there that groups mostly used functions into a single instance, while in pascal every executable replicates the very same code for each instance. make sysutils/runtime etc an external loadable library and we are going to see FPC generate similar sized executables for similarly sized programs. 2012/4/29 Jonas Maebe : > > On 29 Apr 2012, at 12:22, Florian Klämpfl wrote: > >> Spent more man power into optimizer development, though some >> optimizations are hard in pascal because we assume stricter aliasing >> rules and because we don't have a volatile keyword. > > At least as far as our current optimizers are concerned, nothing is volatile > in Pascal: both the assembler and node tree optimizers will replace multiple > loads of global data with a single load when they can. So that should not > limit any optimizations at this time. > > Regarding aliasing, I'm not sure whether C defines anything regarding that. > You at least need to use the -fstrict-aliasing gcc flag to tell it to assume > that pointers to different types cannot alias each other (and hence get > better optimizations). In standard Pascal, pointers by definition can only > point to data of one particular type, so it could be compiled with > -fstrict-aliasing in any case. Since in FPC/Delphi this is no longer the > case, you could introduce a similar switch there to allow programmers to tell > the compiler that their code also obeys strict aliasing rules. > > In general, I think it's indeed simply a matter of the amount of man power > spent on optimizations. > > > Jonas___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
On 29 Apr 2012, at 14:23, Jorge Aldo G. de F. Junior wrote: > What would be usefull is to move the loads of code stored in > sysutils/runtime into a dll/so. That's mainly useful if the external API of the RTL will ever stabilize, which is certainly not the case today. Otherwise you create a dynamic library hell. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Am 29.04.2012 14:23, schrieb Jorge Aldo G. de F. Junior: > What would be usefull is to move the loads of code stored in > sysutils/runtime into a dll/so. > > thats what makes C code look "smaller", theres a nice libc (and > others) there that groups mostly used functions into a single > instance, while in pascal every executable replicates the very same > code for each instance. > > make sysutils/runtime etc an external loadable library and we are > going to see FPC generate similar sized executables for similarly > sized programs. It makes them look smaller but their footprint is actually larger so this is exactly what Ido doesn't want. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Jonas Maebe wrote: On 29 Apr 2012, at 14:23, Jorge Aldo G. de F. Junior wrote: What would be usefull is to move the loads of code stored in sysutils/runtime into a dll/so. That's mainly useful if the external API of the RTL will ever stabilize, which is certainly not the case today. Otherwise you create a dynamic library hell. I had to download somebody's archive viewer a few weeks ago: first there was his binary, then there were his custom DLLs, then there was the MS runtime. I think it came to about 100Mb in total, which made the equivalent written using Lazarus look pretty good- once we'd thrashed out some smartlinking issues. However there's a definite acceptance problem: in the past I've talked to people who insisted in programming in C "because the customer might be bothered about what language we use". Since ABIs (i.e. calling conventions etc.) have settled down a lot since those days it should, in theory, no longer be an issue: but I suspect that many old prejudices remain. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
If you deploy one executable, ok, but if you want to create a handfull of executables (following unix logic of many small programs) then you have a problem. EVERY executable will have the same code again again again, i think libraries have been created to address exactly this issue. about the library hell, why we cant use lib versions ? lets say, libpas.so.2.4.4 for fpc 2.4.4 libpas.so.2.6.1 for fpc 2.6.1 libpas.sysutils.so.2.4.4 libpas.classes.so.2.4.4 etc... etc... the only problem i see is the lack of a sane way to export class instances to/from the libraries. 2012/4/29 Florian Klämpfl : > Am 29.04.2012 14:23, schrieb Jorge Aldo G. de F. Junior: >> What would be usefull is to move the loads of code stored in >> sysutils/runtime into a dll/so. >> >> thats what makes C code look "smaller", theres a nice libc (and >> others) there that groups mostly used functions into a single >> instance, while in pascal every executable replicates the very same >> code for each instance. >> >> make sysutils/runtime etc an external loadable library and we are >> going to see FPC generate similar sized executables for similarly >> sized programs. > > It makes them look smaller but their footprint is actually larger so > this is exactly what Ido doesn't want. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
On 29 Apr 2012, at 15:13, Jorge Aldo G. de F. Junior wrote: > If you deploy one executable, ok, but if you want to create a handfull > of executables (following unix logic of many small programs) then you > have a problem. You certainly do end up with larger executables. Whether or not this is a problem depends on the situation. > EVERY executable will have the same code again again again, i think > libraries have been created to address exactly this issue. That's true. > about the library hell, why we cant use lib versions ? > > lets say, > > libpas.so.2.4.4 for fpc 2.4.4 > libpas.so.2.6.1 for fpc 2.6.1 There is a new FPC 2.6.1 every time a revision is committed to the fixes_2_6 branch. Also, these libpas.so files would be quite large (about 21MB for FPC 2.6.0). You need quite a few small unix utilities to compensate for that in terms of disk space. Of course, you will also reduce memory usage somewhat in case you run several of those utilities at the same time when using dynamic libraries (but startup will be a little slower due to the run time relocation and copy-on-write). > the only problem i see is the lack of a sane way to export class > instances to/from the libraries. That's what (the as of yet unsupported) Delphi-style packages solve. They have the same versioning issue though. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior: > If you deploy one executable, ok, but if you want to create a handfull > of executables (following unix logic of many small programs) then you > have a problem. Indeed, but I don't think this is the way FPC programs are typically used. > > EVERY executable will have the same code again again again, i think > libraries have been created to address exactly this issue. > > about the library hell, why we cant use lib versions ? Because nobody is interested in doing so? Else we got already patches for the install builders to contain .so as well. FPC can create shared libs on unixes and with small flaws, it even works ;) florian@ubuntu32:~$ ldd ./test libfprtl-2.7.1.so => /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so (0x008d3000) florian@ubuntu32:~$ ls -la /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so florian@ubuntu32:~$ ./test Hello world Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! florian@ubuntu32:~$ > > lets say, > > libpas.so.2.4.4 for fpc 2.4.4 > libpas.so.2.6.1 for fpc 2.6.1 > libpas.sysutils.so.2.4.4 > libpas.classes.so.2.4.4 > > etc... > etc... > > the only problem i see is the lack of a sane way to export class > instances to/from the libraries. For .so this is no problem, they act just like simple libs. > > 2012/4/29 Florian Klämpfl : >> Am 29.04.2012 14:23, schrieb Jorge Aldo G. de F. Junior: >>> What would be usefull is to move the loads of code stored in >>> sysutils/runtime into a dll/so. >>> >>> thats what makes C code look "smaller", theres a nice libc (and >>> others) there that groups mostly used functions into a single >>> instance, while in pascal every executable replicates the very same >>> code for each instance. >>> >>> make sysutils/runtime etc an external loadable library and we are >>> going to see FPC generate similar sized executables for similarly >>> sized programs. >> >> It makes them look smaller but their footprint is actually larger so >> this is exactly what Ido doesn't want. >> ___ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
In our previous episode, Florian Kl?mpfl said: > > make sysutils/runtime etc an external loadable library and we are > > going to see FPC generate similar sized executables for similarly > > sized programs. > > It makes them look smaller but their footprint is actually larger so > this is exactly what Ido doesn't want. And on top of that it sounds like there are lumbering assumptions that smaller is also faster. Something that definitely isn't true when you move from static to dynamic linking. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Hi On Sun, 2012-04-29 at 15:50 +0200, Florian Klämpfl wrote: > Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior: > > If you deploy one executable, ok, but if you want to create a handfull > > of executables (following unix logic of many small programs) then you > > have a problem. > > Indeed, but I don't think this is the way FPC programs are typically used. > > > > > EVERY executable will have the same code again again again, i think > > libraries have been created to address exactly this issue. > > > > about the library hell, why we cant use lib versions ? > > Because nobody is interested in doing so? Else we got already patches > for the install builders to contain .so as well. FPC can create shared > libs on unixes and with small flaws, it even works ;) > > florian@ubuntu32:~$ ldd ./test > libfprtl-2.7.1.so => > /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7, Actually, this output shows the bug already: for some reason it does not link to ld.so as well. I thought I had fixed that some time ago. > .1.so (0x008d3000) > florian@ubuntu32:~$ ls -la > /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so > -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 > /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so > florian@ubuntu32:~$ ./test > Hello world > Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns > != 0 || i == nloaded' failed! And that's exactly what happens if the library is missing the reference to ld.so on ubuntu ... I will have a look why this broke (again). Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Am 29.04.2012 17:34, schrieb Thomas Schatzl: > Hi > On Sun, 2012-04-29 at 15:50 +0200, Florian Klämpfl wrote: >> Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior: >>> If you deploy one executable, ok, but if you want to create a handfull >>> of executables (following unix logic of many small programs) then you >>> have a problem. >> >> Indeed, but I don't think this is the way FPC programs are typically used. >> >>> >>> EVERY executable will have the same code again again again, i think >>> libraries have been created to address exactly this issue. >>> >>> about the library hell, why we cant use lib versions ? >> >> Because nobody is interested in doing so? Else we got already patches >> for the install builders to contain .so as well. FPC can create shared >> libs on unixes and with small flaws, it even works ;) >> >> florian@ubuntu32:~$ ldd ./test >> libfprtl-2.7.1.so => >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7, > > Actually, this output shows the bug already: for some reason it does not > link to ld.so as well. > I thought I had fixed that some time ago. > >> .1.so (0x008d3000) >> florian@ubuntu32:~$ ls -la >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so >> -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so >> florian@ubuntu32:~$ ./test >> Hello world >> Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns >> != 0 || i == nloaded' failed! > > And that's exactly what happens if the library is missing the reference > to ld.so on ubuntu ... > > I will have a look why this broke (again). Does libfprtl have to reference ld.so or the main program? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Hi, On Sun, 2012-04-29 at 17:38 +0200, Florian Klämpfl wrote: > Am 29.04.2012 17:34, schrieb Thomas Schatzl: > > Hi > >> florian@ubuntu32:~$ ldd ./test > >> libfprtl-2.7.1.so => > >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7, > > > > Actually, this output shows the bug already: for some reason it does not > > link to ld.so as well. > > I thought I had fixed that some time ago. > > > >> .1.so (0x008d3000) > >> florian@ubuntu32:~$ ls -la > >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so > >> -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 > >> /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so > >> florian@ubuntu32:~$ ./test > >> Hello world > >> Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns > >> != 0 || i == nloaded' failed! > > > > And that's exactly what happens if the library is missing the reference > > to ld.so on ubuntu ... > > > > I will have a look why this broke (again). > > Does libfprtl have to reference ld.so or the main program? > iirc it is sufficient that libfprtl references it. But that error message is just what you get if it does not. So maybe my reply was too quick. I will have a try and see anyway; further thinking about it, if there were changes to that code, the corresponding testsuite programs should fail too, so maybe the original changes just work for some cases or cover up the real issue. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Interested people might want to have a look at http://bugs.freepascal.org/view.php?id=12492 there are iirc still unprocessed patches in that report. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Am 29.04.2012 17:50, schrieb Thomas Schatzl: > Hi, > > On Sun, 2012-04-29 at 17:38 +0200, Florian Klämpfl wrote: >> Am 29.04.2012 17:34, schrieb Thomas Schatzl: >>> Hi florian@ubuntu32:~$ ldd ./test libfprtl-2.7.1.so => /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7, >>> >>> Actually, this output shows the bug already: for some reason it does not >>> link to ld.so as well. >>> I thought I had fixed that some time ago. >>> .1.so (0x008d3000) florian@ubuntu32:~$ ls -la /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so florian@ubuntu32:~$ ./test Hello world Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! >>> >>> And that's exactly what happens if the library is missing the reference >>> to ld.so on ubuntu ... >>> >>> I will have a look why this broke (again). >> >> Does libfprtl have to reference ld.so or the main program? >> > > iirc it is sufficient that libfprtl references it. But that error > message is just what you get if it does not. So maybe my reply was too > quick. > > I will have a try and see anyway; further thinking about it, if there > were changes to that code, the corresponding testsuite programs should > fail too, so maybe the original changes just work for some cases or > cover up the real issue. libfprtl is generated by ppumove and not the compiler so this might be the reason. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
