Slashdot Mirror
Simpler "Hello World" Demonstrated In C
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!"
Interesting, but she does sort of sidestep the whole 'Hello World!' part of a hello world program.
FYI, Steve Jobs came up with the idea for the "Hello World" app.
He also holds the design patent on the touch wheel interface for it.
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
http://web.archive.org/web/19991128041233/http://muppetlabs.com/~breadbox/software/tiny/teensy.html
November 1999. Slow news day much?
This post expresses my opinion, not that of my employer. And yes, IAAL.
45 bytes, huh? I can do it in....
#!/bin/sh
exit 42
18 bytes and it's portable across all Unices. Maybe the assembler version is faster, though?
I think you missed the point of the article.
The author is trying to highlight that amount of bloat in modern programs is so rampant that even "Hello World" is excessively over sized for what it accomplishes. How can we as programmers expect fast, efficient, lightweight code when our compiler (even ones as popular as gcc) are bloating the program without being asked to?
As to the point of this... we recently had a story about how computers had gotten "too big to understand".
And here we have a program, 45 bytes long, for which every single byte has a well-explained purpose. It's getting back to the bare metal and that's what makes it interesting. =)
At the end, the code was assembler, and the compiler wasn't even called - just the linker. I can't say for sure where a C program ends and an assembler program begins, but I'm fairly certain that the last few iterations are assembler, based on the "let's do away with the compiler" suggestion.
Also, "Hello World" programs have to, you know, actually display the message "Hello World" - this is a program that isn't written in C, and doesn't write "Hello World" - care to revisit the title of this entry?
Ken
Thank God we have finally crossed this hurdle. The baffling complexity of helloworld.c is no longer an obstacle to world domination.
I think we can now finally say once and for all that 2010 will be the year of Linux on the desktop.
But my stupid build process that generates the bloated Hello World is much more maintainable. Now get off my lawn.
Colorless green Cthulhu waits dreaming furiously.
No Steve Jobs designed "iHello World", which is actually one byte larger than the standard hello world app, but he's litigating against everyone who creates "Hello World" since 100% of it is quite obviously a subset of "iHello World".
I drink to make other people interesting!
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).
We live, as we dream -- alone....
Maybe thinking like that is why we have to get 4 gigs of ram to run without slowing down lately. I bet every executable on the hard drive has an extra 11k that somebody thought was insignificant.
This is basic knowledge that ANYONE using c should know - that the startup library is linked to so it can find main.
This is almost as lame as their previous slashvertisement/product_whoring - where they claimed to have gotten around the Mythical Man-Month and quadrupled output - and it turned out that neither claim was true.
And their lame excuse, which I derided in this comment:
I'm sure we're not the only ones to have used embedded assembler in c programs.
Mod parent up. This is all a semantic game about where significant portions of functionality are stored (and thus counted or not). After all, back in the "pre bloatware" days, you'd have had to manage all of the complexities of machine management and I/O yourself. The assembly would have been much larger to achieve the same effect.
Yes, you can make the argument that Linux comes with screen I/O, a scheduler, memory management, etc. already, so that's just overhead, but as others have pointed out, you can say the same thing about bash. It comes everywhere and is just overhead.
STOP . AMERICA . NOW
c:\ xxx>debug :001D
-a
mov dx, 100
mov cx, 000D
mov bx, 1
mov ah, 40
int 21
mov ah, 4C
int 21
-f 111 "Hello World!"
-a100
mov dx, 0111
-r cx
-n c:\ xxx\ hello.com
-w
-q
c:\ xxx>hello.com
Hello World!
c:\ xxx>dir hello.com
03/18/2011 11:29 AM 29 HELLO.COM
Try programming a micro-controller and suddenly you'll be facing hardware limits that force you to favor small unreadable code over bigger more maintainable code. There is a solution for it though... comments! Lots of them :D
The fact that people would even still use C at all for anything anywhere ever shocks me.
I started writing device drivers in Ruby, and have never looked back.
In order to get Ruby to run on my system, I run it in an interpreter. The interpreter is written in Java, which is a much faster language and therefore more suitable as an interpreter.
The JVM on my system is written in C#. I know that C# is comparable to Java in terms of efficiency, but since this is a Windows machine, I figure it's "closer to the metal."
The implementation of the .NET framework on my computer (and the Windows operating system itself) is written in Ruby. Since I already have a Ruby interpreter on my system, this presents no problems.
I don't believe in time. It's a grand conspiracy designed to sell watches.
It's too bad with all these things you "heard" that you didn't happen to hear that programs are written for environments other than Windows (or Linux, Mac OS, etc), and for devices other than PCs. It's unfortunate that you are so in the dark that you don't realize that there are entire industries that rely on devices that have tiny fractions of the memory and processor speed that you ignorantly assume that we all have access too. You probably have no idea how often you are affected by devices that run 100 times slower than the desktop PC you gave as an example, or also have 1,000 times less RAM. On some of these devices C is the most advanced language you can get short of writing a compiler or interpreter yourself.
Sure, pissing away storage space and waving a hand at execution efficiency is fine for some circumstances, but sometimes it's a luxury you can't afford. The world of software development is far bigger than the tiny little niche of programming you've been exposed to.
I suggest you use some "real" perspective, and reevaluate what a "real language" is.
She found that gcc was including libc even when you don't ask for it.
This is basic knowledge that ANYONE using c should know - that the startup library is linked to so it can find main.
Okay, and where am I supposed to learn it from? That was new to me, after using gcc for a very long time.
I'm actually very happy that someone out there told me something that you think I should just know.
So it wasn't new to you? Don't read it.