[danengel]

Hi,

I wrote a somewhat complex "Hello world" app. First I load "putchar" from the System Libraries using the Code Fragment Manager. With this "putchar" I say "Hello world", that's it. Written using Project Builder, about 30 lines of code are required, but the executable file is about 200 KB big! WTF ? I really don't want such a huge application, I think one or two KB would be enough.

Somebody please explain this or tell me how to get rid of any unused bytes.

Thanks,
Daniel

[ali]

Your executable has debug information. Once this is removed, it should be down to a much leaner size.

One way to do this is use the "install" target, which will build and install the tool in /tmp. You can also do "pbxbuild install DSTROOT=/somepath", which will install it under the specified location.

Ali

[Millennium]

Interesting point. But why did you use putchar? I'd think printf or NSLog would suffice for a Hello World app, unless you were doing something graphical.

[Apocalypse]

You can also choose to disable these debug tokens in project builder itself. It is under the target settings (go to edit active target). There are options for code optimization and debug symbol generation. This is more of a permanent and, in my opinion, convenient way of solving this problem than the INSTALL solution suggested above.

Jeff.

[danengel]

Oops, I'm so stupid I haven't seen that before... after I disabled the debugging-something-info, the code size shrinked to 9K, still a lot, but definitely better than 200K.

The reason for using putchar: Ok, I'm about to write an (Forth-, ever heard that before? Hardly, veery unknown...)interpreter in which I'd like to be able to load libraries and using their functions, but I don't want to link with all the 1000 libraries on the system. The only thing my interpreter needs is to get (1) one char out and (2) one char in, that's all it sees from the outer world, except (3) dynamic library linking. I felt that putchar was the most basic (and thus fastest) way to get a single char out to the terminal (Oh yes, it's a terminal app, BTW). That's why.

[Dalgo]

9k does seem to be a lot for just a hello world type app. So I decided to check out what was making the bloat. I compiled:

#include <stdio.h>

int main()
{
printf("Hello World!");
return 0;
}

with the -O3 command. The resulting executable, was 9456 bytes or ~9k. Now, compiling with the -O3 and -S directives, in order to give me assembly output, left me with a short assembly file. The difference here is that the printf function wasn't inline in the assembly file. When I used otool to disassemble the executable, then I saw a much larger file so the printf function must be the bloated part. Actually, when you think about it, 9k is pretty bloated for a simple hello world program. I mean, when computers were pretty much dumb terminals, 9k would have been a lot considering that the usual memory in those was <64k.

Yes, increasingly fast computers permit increasingly bloated code.

An interesting side note. This is the assembly code that is at the very beginning of the compiled file, when disassembled:

(__TEXT,__text) section
start:
00001be4 or r26,r1,r1
00001be8 addi r1,r1,0xfffc
00001bec rlwinm r1,r1,0,0,26

Here it looks like it is backing up the value of r1 into r26 and then loading an address into r1. I'd guess that it is setting up the stack and the new address of the stack lives in r1. My question is: does the stack always begin at the same relative address for every program and what was in r1 when the program was first launched?

[danengel]

Yes, increasingly fast computers permit increasingly bloated code

Hell yes I hate this. Just because everybody thinks he/she can add a little overhead here and there and it wouldn't matter because "my gigaflop sure can handle some 1000 instructions more" we are where we're now: Incredibly fast computers with CPU's and amounts of RAM and HD that would blow away every supercomputer 10 years ago, but to start "TextEdit" it takes 10 seconds, aaaah! That's one of the reasons I try to write an interpreter, one which is as small as possible, not wasting a single byte.

does the stack always begin at the same relative address for every program and what was in r1 when the program was first launched?

Oh yes, that's very interesting. Weird that the last 4 bits of r1 are zeroed... I think you could find some information about this in the "Runtime Conventions".