Hi all,
I'm new in GNU Pascal and wonder the exe size compiler produces. Three lines Hello World source was blowed up to the 349 KB (!) exe. Stripped down (with -s) the executable is still big - 247 KB. The same source compiled with VirtualPascal's compiler is 11 KB exe. 20 times smaller! Am I doing something wrong?
Thank in advance, Peter
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
At 10:14 PM -0800 21/1/04, Peter Norton wrote:
I'm new in GNU Pascal and wonder the exe size compiler produces. Three lines Hello World source was blowed up to the 349 KB (!) exe. Stripped down (with -s) the executable is still big - 247 KB. The same source compiled with VirtualPascal's compiler is 11 KB exe. 20 times smaller! Am I doing something wrong?
We have a similar issue under Mac OS X.
The issue (as I understand it for us) is two fold, the fact the no dead code stripping is done means that any code in any imported statically linked library is included with nothing removed, and then the size of the various libraries including the gpc runtime library.
Although space is "cheap" these days, it is a pain since it limits what you can break down as small self contained utilities since each one is large.
I imagine the Windows version has the same issues.
I'm not sure if dead code stripping is something that the linker does on some platforms and not others, or whether it is on the agenda for improving. It's probably not really a GPC issue at all, but more a gcc backend linker issue. Peter.
On Thu, 22 Jan 2004, Peter N Lewis wrote:
At 10:14 PM -0800 21/1/04, Peter Norton wrote:
I'm new in GNU Pascal and wonder the exe size compiler produces. Three lines Hello World source was blowed up to the 349 KB (!) exe. Stripped down (with -s) the executable is still big - 247 KB. The same source compiled with VirtualPascal's compiler is 11 KB exe. 20 times smaller! Am I doing something wrong?
We have a similar issue under Mac OS X.
The issue (as I understand it for us) is two fold, the fact the no dead code stripping is done means that any code in any imported statically linked library is included with nothing removed, and then the size of the various libraries including the gpc runtime library.
In addition to the dead code there is also program startup and shutdown routines. Interesting to note the difference between a "do nothing" program ( just a "begin end." ) and hello world is about 64 bytes.
Russ
On 22 Jan 2004 at 14:56, Peter N Lewis wrote:
At 10:14 PM -0800 21/1/04, Peter Norton wrote:
I'm new in GNU Pascal and wonder the exe size compiler produces. Three lines Hello World source was blowed up to the 349 KB (!) exe. Stripped down (with -s) the executable is still big - 247 KB. The same source compiled with VirtualPascal's compiler is 11 KB exe. 20 times smaller! Am I doing something wrong?
We have a similar issue under Mac OS X.
The issue exists on all GPC platforms.
[...]
I'm not sure if dead code stripping is something that the linker does on some platforms and not others, or whether it is on the agenda for improving. It's probably not really a GPC issue at all, but more a gcc backend linker issue.
I believe it is mainly a gpc issue although one cannot of course totally eliminate gnu binutils from the equation. The problem, as I understand it, is that the linker cannot discard unused routines, unless each routine is in self-contained object file. A lot of gcc libraries are of course arranged in this way - i.e., each contains a whole load of object files, each representing a function - so when the library is linked, the linker can discard the object file(s) representing the function(s) that is(are) not referenced at all. Seems that gcc programmers who write libraries are accustomed to coding in this way (perhaps enforced by the features of the linker).
With gpc, we don't (with for example the RTS (libgpc.a)) separate each routine into a separate source file like gcc programmers do. Furthermore, the routines in each gpc unit are each encompassed in one single object file. This means that, with every unit that is used, all the routines get linked into the program, because the linker cannot separate them. The same goes for the gpc runtime library (libgpc.a). So the smallest gpc program will be at least as big as the sum of the object files in libgpc.a (or something generally along those lines anyway).
I have discussed this with Frank sometime in the recent past, and IIRC, the sum of the discussion was that the most straightforward solution (other than doing things the gcc way) would be to find a way of separating each routine, on compilation, into its own object file. There seem to be some mechanisms within the compiler and binutils to assist in doing this - the switches: "-fdata-sections" and "-ffunction- sections" passed on to the compiler, and then objcopy with the switch "--only-section".
I gave this a go sometime last summer and was "somewhat" successful (meaning I managed to separate the routines, etc., but only produced programs that crashed). In the end, I gave up, due to lack of time and perhaps the necessary knowledge. If someone has the time to look into it, I can pass on to you the details of my unsuccessful attempts - basically a simple gpc program that converts object files from gpc units that had been compiled with "-ffunction-sections" into a gnu library archive, after separating the functions (basically a shell to "objcopy").
If there is any general interest, I can upload the program source (3 different permutations, each with varying degrees of failure when put to the test), and perhaps if all of us put our minds to it, we could come up with some sort of solution that could eventually be integrated into gpc itself.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Peter N Lewis wrote:
Peter Norton wrote: The issue (as I understand it for us) is two fold, the fact the no dead code stripping is done means that any code in any imported statically linked library is included with nothing removed, and then the size of the various libraries including the gpc runtime library.
The linker *can* strip dead code (as I understand it) per section, not per function. However, each section is referenced, because it contains the unit's initialization code (even if the initialization code does nothing). The nett result is that no dead code is stripped at all.
Although space is "cheap" these days, it is a pain since it limits what you can break down as small self contained utilities since each one is large.
I fully agree it's a pain.
I imagine the Windows version has the same issues.
I'm not sure if dead code stripping is something that the linker does on some platforms and not others, or whether it is on the agenda for improving. It's probably not really a GPC issue at all, but more a gcc backend linker issue.
Partly it is a gpc issue. Try to compile hello.c, also see http://www.gnu-pascal.de/crystal/gpc/en/mail7764.html.
Prof A Olowofoyeku (The African Chief) wrote:
I have discussed this with Frank sometime in the recent past, and IIRC, the sum of the discussion was that the most straightforward solution (other than doing things the gcc way) would be to find a way of separating each routine, on compilation, into its own object file. There seem to be some mechanisms within the compiler and binutils to assist in doing this - the switches: "-fdata-sections" and "-ffunction- sections" passed on to the compiler, and then objcopy with the switch "--only-section".
Unfortunately, not all platforms support --function-sections, e.g. Mac OS X doesn't.
Regards,
Adriaan van Os
On 22 Jan 2004 at 16:31, Adriaan van Os wrote:
[...]
There seem to be some mechanisms within the compiler and binutils to assist in doing this - the switches: "-fdata-sections" and "-ffunction- sections" passed on to the compiler, and then objcopy with the switch "--only-section".
Unfortunately, not all platforms support --function-sections, e.g. Mac OS X doesn't.
In which case, if this method works, then there is the option of trying to get the porters of gcc to OS X to add support for "-ffunction- sections". The other option (i.e., doing it the gcc way) is not going to be viable.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
-
Adriaan van Os -
Peter N Lewis -
Peter Norton -
Prof A Olowofoyeku (The African Chief) -
Russell Whitaker