Simpler "Hello World" Demonstrated In C 582
An anonymous reader writes "Wondering where all that bloat comes from, causing even the classic 'Hello world' to weigh in at 11 KB? An MIT programmer decided to make a Linux C program so simple, she could explain every byte of the assembly. She found that gcc was including libc even when you don't ask for it. The blog shows how to compile a much simpler 'Hello world,' using no libraries at all. This takes me back to the days of programming bare-metal on DOS!"
Old news is VERY OLD (Score:5, Informative)
http://web.archive.org/web/19991128041233/http://muppetlabs.com/~breadbox/software/tiny/teensy.html [archive.org]
November 1999. Slow news day much?
Re:BTDT (Score:2, Informative)
The muppetlabs link ends with the entire program overlapped into the ELF header, and part of the header left off.
(It is just a toy program that returns 42 to the OS, but he gets it down to 45 bytes.)
Re:Old news is VERY OLD (Score:5, Informative)
Indeed, this is very old news, it's been done many times before. I recall reading and applying this article for Windows many years ago:
http://msdn.microsoft.com/en-us/magazine/cc301696.aspx [microsoft.com]
there's also: http://www.ntcore.com/files/SmallAppWiz.htm [ntcore.com] and http://www.phreedom.org/solar/code/tinype/ [phreedom.org] (again for windows) and many more.
Re:Umm, but (Score:3, Informative)
And I guess if you'd read the blog (the second link in the article not the third) which the summary is actually referring to, you would know that there is no output from the program written by the "MIT programmer [who] decided to make a Linux C program so simple, she could explain every byte of the assembly".
Re:11k Is Too Big? (Score:4, Informative)
The whole point was learning ELF structure and why things were they way they were. Didn't you ever wonder why a "hello world" program took over 4000 bytes on a modern computer, when in 1980 a Commodore VIC-20 managed to play games in less than 4K of available memory? This wasn't a waste of time.
Re:Simpler "Hello World" in C? (Score:3, Informative)
That is it - the whole program.
Doesn't say "Hello" to me!
Re:I can code that app in... (Score:1, Informative)
Commodore BASIC:
?42
Re:I can code that app in... (Score:2, Informative)
If you want to clear the screen and add a new line: w #,42,!
Re:11k Is Too Big? (Score:2, Informative)
This is because we are no longer linking the binaries statically (one object file for each function), but are using dynamically linked libraries. And your libc is't loaded only for your program. The same spot in ram is shared between all programs that are using it making the total ram spent for each program rather small, probably even smaller than if you would statically link the object files of the functions you need.
Re:C++ is worse (Score:5, Informative)
Shouldn't the linker remove unreferenced functions?
I've had this problem with gcc for a while, with C++ code. I was writing some embedded code, and I wanted to use some simple C++. Just by adding a #include of one of the stream libraries. the executable grew by 200k, even though none of it was referenced. The C++ code in iostream is template-generated anyway, so even if the compiler wanted to include the code, it can't until I instantiate it.
<iostream> includes references to global stream objects like std::cout, not just interface definitions, so including it's going to have larger ramifications that something like <fstream>, which just defines interfaces (and indeed, for me, including <fstream> seems to have no effect on program size, whereas including <iostream> adds about 300 bytes to a simple executable).
Not a C program (Score:5, Informative)
I wasted too much time reading this one... nothing surprising about what I found in it. Step one, don't write it in C. Step two, stop linking to things that aren't needed. Step three, perform the functions contained in the library omitted manually. Step five, start cheating in the elf binary format.
The only thing interesting about it was that the article pointed out an interesting fact -- Linux will run inappropriately formatted binaries. BAD. Linux kernel people? Are you reading this? Fix it before someone figures out how to use this in making and executing more exploits.
Damn kids (Score:3, Informative)
Back in the DOS days, any moderately competent programmer knew how to copy arbitrary data to screen buffer, allowing you to display text without any libraries. It's been many years, so I am probably getting this wrong, but in psuedocode it'd look something like
char*cp="Hello World";
char *addr=0xB8000000;
while(*addr++ = *cp++);
That's the C version, of course. You'd actually do it in assembly. My suspicion is that you could do it in on the order of 20 to 25 bytes, but again, it's been decades since I've done anything like that.
Re:11k Is Too Big? (Score:4, Informative)
Re:Old news is VERY OLD (Score:3, Informative)
November 1999. Slow news day much?
That would explain why as I followed the exercise along in my terminal, I got this warning:
"ld: warning: option -s is obsolete and being ignored"
A decade obsolete as it turns out. I suppose when PC's started measuring their RAM in gigabytes, there was little need to strip executables anymore. Still, the article was a very fun read and took me back to the 80's when I was programming at the byte level myself. See also: One-line programming contests and the like. Much more fun (to me) than today's object-oriented everything.
Re:11k Is Too Big? (Score:5, Informative)
gcc for an AVR target doesn't make an 11k hello world, though.
Probably because that's an application where it matters, and a modern PC it doesn't matter at all.
The summary headline is crap (Score:5, Informative)
Re:BTDT (Score:5, Informative)
What a shock this comes from Kdawson. I'm about one more kdawson article away from dumping slashdot. I can't imagine that all the people in the slashdot batcave aren't laughing at this tool.
I sometimes wonder if he just goes out and gets completely hammered at lunch then comes back and picks a few articles.
Apple defines system call APIs at the top of libc (Score:4, Informative)
Apple defines system call APIs at the top of libc ...no static linking allowed.
This annoys people who like to link things statically, and those who want to make their own libc equivalents for things like embedded language interpreters and don't want to have to figure out vtables and dynamic linking.
But it also makes everyone else who likes binary compatibility, and Mac OS X historically getting faster with every release, extremely happy, by allowing the interface between the kernel and libc to be changed, without breaking their applications.
If you statically link, you can't do that. That's great, if your OS has pretty much no real commercial application base, and you are a technical enough person to "just recompile everything from source", but it's not so good when you are talking about an OS where commercial software is very important to customers. Customers who are either non-technical, or who are technical, but think recompiling something that was working just fine before the OS update is a complete waste of time. Lump me in with these last people: I don't believe in "bit rot", I just believe in lazy engineers not maintaining their code or defining their interfaces properly.
Yeah, if you want fast LMBench results on a null system call -- which keeps changing its definition so that it can't be gamed, exactly the same way you'd game it if you were a commercial application developer needing higher performance -- static linking seems great. But practically, most modern software is either CPU bound or I/O bound. If it's CPU bound, it spends all its time in user space, not making system calls. If it's I/O bound, it spends all its time waiting for whoever is on the other end of the network to send it more bytes. Either way, null system call performance is, frankly, unimportant to almost every possible application.
So static linking, and writing your system calls at the trap/sysenter/syscall level (with no way to change them when Intel or another chip vendor introduce a "new! optimized method of making system calls!", as has already happened twice in the past) is generally a pretty useless exercise.
-- Terry
Re:11k Is Too Big? (Score:3, Informative)
Re:BTDT (Score:3, Informative)
It is just a toy program that returns 42 to the OS, but he gets it down to 45 bytes.
Since computer science tends to be such a male dominated field, I think it's worth pointing out that the author is a woman [mit.edu].
Yes (Score:1, Informative)
Re:11k Is Too Big? (Score:2, Informative)
The whole point was learning ELF structure and why things were they way they were. Didn't you ever wonder why a "hello world" program took over 4000 bytes on a modern computer, when in 1980 a Commodore VIC-20 managed to play games in less than 4K of available memory? This wasn't a waste of time.
Yeah.
To put this in perspective: Guess how big the executable header is in 8-bit Commodore machines?
2 bytes. The absolute start address of the program. The computer opens up the file, reads where it's stored, and starts putting data to the memory from that point onward. Simple enough. Of course, there's none of this "relocation" and "memory protection" rubbish to worry about.
If you wanted to store program in BASIC RAM, you could write a stub BASIC program that basically just has one code line, 10 SYS<startaddr>, where <startaddr> points to the address past the end of the program in BASIC RAM. In total, this "header" is just a dozen bytes or so in tokenised BASIC. (Don't have the time today to test how small I can make it, but...)
exe vs com (Score:1, Informative)
There were a discussion at some game dev forum a few years ago, using VS60 (which compiles to win32 exe) some person come up with a ~400 bytes exe file (doing nothing).
Using DOS, a 14 bytes program is enough:
MOV AH,09
MOV DX,0108
INT 21
RET
DEC AX
DB 65
DB 6C
DB 6C
DB 6F
DB 24
-------
14 bytes.
With INT 21 (requires DOS). A couple more if only using BIOS/INT10 (no OS), must then print each char as individual characters, cannot print a whole string in 1 call.
Re:BTDT (Score:3, Informative)
I don't think Un*x ever did.
UNIX used the sticky bit instead. UNIX also supported Split I&D on the 11/70 before M+ came out with Split I&D support on RSX.
I don't think you're remembering right about overlays on RSX. I know I spent WAY too much time waiting for TKB on RSX because it was sitting there trying to cram stuff into overlays. Also, while later PDP-11s technically could support demand paging the 8k page size in a max of 64k addressible memory made it a marginal technique, and I'm pretty sure it was never used, even by M+.
UNIX supported shared code, too. We had over 35 users at a time on the Cory Hall 11/70 at Berkeley. It was OK under Version 6, but got painfully slow during finals week after they upgraded to Version 7. The Math/Stat department had an 11/60 and could only handle 8 users under UNIX, almost 20 under RSTS... but nobody wanted to use RSTS. We called it "Really Shitty Time Sharing".
Some of the guys managed to patch RSTS Basic+ to run under UNIX by taking advantage of the fact that UNIX used the TRAP instruction for system calls and RSTS used the IOT instruction, by cramming an IOT handler into the half a kilobyte DEC had left for the stack at the beginning of the core image to emulate the RSTS calls that Basic+ needed. That way they could upgrade the business school to UNIX and get rid of the last RSTS holdout on campus.
Re:How about 28 bytes?! (Score:4, Informative)
C:\>debug
-a 0100
0D39:0100 MOV AH,09
0D39:0102 MOV DX,0109
0D39:0105 INT 21
0D39:0107 INT 20
0D39:0109
-e 0109 'Hello world!$'
-r cx
CX 0000
-n hello.com
-w
Writing 00016 bytes
-q
C:\>HELLO.COM
Hello world!
C:\>dir hello.com
26/08/2009 10:48 22 HELLO.COM