Hyperion Entertainment Message Boards

Hello,


When compiling small & simple programs, the size of the compiled executable files gets much larger than they ought to be.
F.ex., a simple "Hello World"-program that only prints that text in the shell occupies as much as 66884 Bytes (even after using the strip-command).
Such a program shouldn't occupy more than a few KBytes.

Compiler used : gcc
Command to reduce filesize: strip
SDK version : v53.20 (1.3.2010)
Hardware : Sam440ep
OS version : Amiga OS 4.1 update 3

Whether this has something to do with the SDK, gcc or strip, I don't know.
What I do know, is that with an older version of the SDK (the previous one, I think), the size of the executable of the same program was around 6-7000 Bytes.

I would be really happy if there exist a workaround (or a bugfix) for this issue.
Thanks in advance for your help.


Below is a test-program for the issue.

/*
Here is what I do to to verify the statement above:
-----------------------------------------------------------------
Step 1)
Compile the program below from the shell, and check the file size.
In addition, have a look in a HEX viewer to see what the executable file contains.
The interesting thing you will see, is that it contains a huge amount of zeros in the beginning of the executable.

gcc -o HelloWorld HelloWorld.c

Result: 67373 Bytes.


Step 2)
Reduce the size of the executable by typing in the below from the shell.
After you have done this, have a look in a HEX viewer to see what the executable file contains.
The interesting thing you will see, is that the zeros found in the original executable, is now replaced by
lots of "unused text".

strip -s HelloWorld

Result: 66884 Bytes.
*/


#include <proto/dos.h>

int main(int32 argc, char* argv[])
{
IDOS->Printf("Hello world!\n");
}

Sounds to me like its compiling a stand alone version by default as opposed to a resource dependency version

I don't really know (since I'm not a coder... yet ) but couldn't help throwing that concept out there!

I don't recognise the code though, perhaps it has something to do with the way you've coded it, anyway, it did seem rather strange to me with my limited understanding

This MAY be due to the extra "padding" they had to add for the Sam440's CPU. I'm not sure we ever got a full explanation, but it seemed to be something that won't be changed.

ChrisH wrote:This MAY be due to the extra "padding" they had to add for the Sam440's CPU. I'm not sure we ever got a full explanation, but it seemed to be something that won't be changed.

It is extra padding, but eventually we found out it was apparently not due to the PPC440, as far as I remember from previous discussions.

Why it is there I think remained unanswered, but it is pretty annoying for small programs.

chris wrote:..it was apparently not due to the PPC440, as far as I remember from previous discussions.

Thomas added the padding for the 440ep. It was the quickest fix at the time.

http://www.amigans.net/modules/xforum/v ... mpost42211

It has nothing to do with the Sam440EP or AmigaOS for that matter. Newer binutils pad the segments in ELF files so that they are 64kb aligned so that they can be easily loaded with mmap() (since mmap() doesn't exist on AmigaOS anyway it's a pretty pointless waste of disk space, but TBH not really that big of a deal). If you really care much about it you can always use VBCC instead which doesn't add such useless padding.

@ jostein_aarbakk
As salas00 say, its not sam440 specific, its just the same for all the aos4 supported cpus/platforms because of newer binutils (gcc/as and so on), which by default build for you paged binary (and by default for ppc its just aligned to 64k now). And not only for sam440, but for all the cpus (as for example for my g4 on peg2).

By link which salas00 provide you on amigans.net, no one by some reasson even trying to do some google, and so by keywords "binutils how disable 64k paging" googl bring some links, one of which are this one, and the important part here:

> Maybe you want -N, for building non-paged binaries.

And so:

6/1.Work:> cat 1.c
#include <stdio.h>
main()
{
printf("aaaaaaa");
}
6/1.Work:> gcc 1.c -o 1
6/1.Work:> ls -la 1
-rwxr-xr-x 1 root wheel 67416 2011-12-23 03:20 1
6/1.Work:> 1
aaaaaaaa

6/1.Work:> gcc -N 1.c -o 1
6/1.Work:> ls -la 1
-rwxr-xr-x 1 root wheel 6016 2011-12-23 03:22 1
6/1.Work:> 1
aaaaaaaa
6/1.Work:> strip 1
-rwxr-xr-x 1 root wheel 5484 2011-12-23 03:23 1
6/1.Work:> 1
aaaaaaaa

Dunno why no one in that old thread from amigans.net bother to check gcc docs or google for that matter, but in end its that easy.

@Kas1e
Well spotted! -N seems to work here.

HOPEFULLY, 64Kb padding isn't actually required by some future version/feature of AmigaOS4...

salass00 wrote:It has nothing to do with the Sam440EP or AmigaOS for that matter.

Thomas added it thinking it fixed an alignment issue on the 440ep. If this is not the case I suppose somebody should let him know...

ssolie wrote:

salass00 wrote:It has nothing to do with the Sam440EP or AmigaOS for that matter.

Thomas added it thinking it fixed an alignment issue on the 440ep. If this is not the case I suppose somebody should let him know...

Thomas did add extra alignment for the Sam440 but this is not what is causing the large noticeable difference in executable size.