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!"
Ok, this is wicked great in theory. Our programs have become bloated. We do have them taking up too much RAM, HD space, and CPU time. But after reading through this in-depth analysis I have to wonder if it's all worth it.
If we're willing to leave behind all pretenses of portability, we can make our program exit without having to link with anything else. First, though, we need to know how to make a system call under Linux.
Or I can just write it the old way, making the file size larger and not have to concern myself with portability and how to make system calls under Linux. After all that's what the whole point of this all was right?
Since when does a Hello World program not actually output anything?
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?
Why doesn't it fit in TFS?
If God forks the Universe every time you roll a die, he'd better have a damned good memory.
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
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.
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.
But it really is much simpler. The reason your 'average first year comp sci student' might find it less understandable is because they dont actually understand the bloated version either. Using a high-level language doesnt reduce complexity, quite the opposite in fact, it greatly increases actual complexity. It simply makes it easier to get something done without understanding it, and thus makes it easier to kid yourself into thinking you know what you are doing, when you dont.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Yeah, but the 45-byte program doesn't say "Hello World". In fact, there's no example that I can find in TFA that outputs that message or any other. So the summary is incorrect on its face. TFA doesn't show a simpler "Hello World" program; it doesn't show any sort of "Hello World" program at all.
I feel cheated, and tricked into reading an article that didn't do what was advertised.
(It's not the author's fault, of course; the author didn't claim to be writing the sort of program that the summary talked about. Though I was a bit disappointed that only the first few examples were in C. The article was almost entirely about assembly-language programs. So again, I was a bit disappointed, since I was hoping to learn something about making C programs smaller. This was done only in the first example, and it was made smaller by removing its call on write() so it didn't output anything at all. I already understood that I can make programs smaller by removing all functionality. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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.
Hm, if I make a file 'hello.py' with the following content:
print 42
And how big is Python?
Granted, but how big is linux, letting you run that ELF?
The fact that helloworld.c compiles to 11k has less to do with bloat than it has to do with people generally not caring about 11k. You could get rid of that 11k, but to do so, you'd have to make trade offs that either make real programs either slower or bigger, or make compilation slower. Very few people would make those trade offs in the other direction. Those that do either use special purpose compilers or (more likely) write in assembly.
The cake is a pie
Most of the microprocessors in the world today have less than a few 10's of kilobytes of RAM. They tend to do useful things most of the time.
I am becoming gerund, destroyer of verbs.
TFA explains it: main() isn't the true start of the program, _start is. That resides in ctrl.o, which fires off a bunch of setup stuff before calling __libc_start_main, which in turn kicks off main(), and off your program goes.
To put it as a car analogy: What she found is that turning the key to start doesn't just activate the starter, it also activates the airbag system, the traction control, and the radio too. And if all you want to do is start the engine to prove that it runs (ala Hello World!), then it's kind of silly to lug around all that extra "unnecessary" crap too.
Or something like that. Sadly i'm a better mechanic than a programmer (4yrs vs 1yr), but i'm working on fixing that. :)
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
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
Since the output is the Answer to the Ultimate Question, it necessarily incorporates or encodes every possible output of every possible program, including the string "Hello World!".
The method for extracting the particular output desired is left as an exercise for the reader.
I bet every executable on the hard drive has an extra 11k that somebody thought was insignificant.
So if you have, say, 1000 open processes, that means your computer is wasting 11 MB of RAM. Such inefficiency!
Actually, the reason you need 4 GB of RAM is because the programs you're using are far more complex than the ones that people were using when 256 MB was top-of-the-line. You may say, "But all I need is to read e-mail and browse the web!" -- except that nowadays those tasks involve rendering GUIs with Javascript, streaming and playing HD video in realtime, and doing constant full-text indexing in the background so that you can quickly search anything for any phrase. On top of that, in the background your operating system is trying to predict what you'll do next and prefetching blocks from your hard drive into RAM so that they'll already be cached when you actually need them.
Some of that RAM is honestly being taken up by insignificant chunks of data, but most of it really is being used.
Karma: Terrifying (mostly affected by atrocities you've committed)
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.
*sigh*
Been there done that... on the PDP-11 in 1979.
And did you write up a nice article for other people to learn from what you had done?
I think the real value here is not that she did this, but that she wrote it up in a nice easy to read way so that you can follow her train of thought and get a feel for how one goes about tinkering with compilers and such.
This adds value for people like me who are not as smart as you. I could never have done this on a PDP-11 (although I did have access to one back in my days at university). I also previously would not have know enough to do this in Linux. But having read this article I feel I have learnt something and have a new insight into how linkers and libraries work. Who knows, maybe I will be able to do something similar myself after this learning experience, and for that I am grateful to Jessica for doing it, writing about it and (I'm guessing it was her) submitting it to /.
Now I shall respectfully step off your lawn.
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.