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!"
BTDT (Score:3, Insightful)
*sigh*
Been there done that... on the PDP-11 in 1979.
Re:BTDT (Score:5, Insightful)
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 [ksplice.com] - 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 [ksplice.com], which I derided in this comment [ksplice.com]:
I'm sure we're not the only ones to have used embedded assembler in c programs.
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.
Re: (Score:3, Insightful)
Re:BTDT (Score:5, Insightful)
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.
Re:BTDT (Score:5, Interesting)
Some people like their code to run on OSes for grownups.
Re:BTDT (Score:5, Funny)
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.
Re:BTDT (Score:5, Funny)
I have a suggestion: If you write your JVM in Visual Basic instead of C#, it'll be portable, since most old microcomputers included BASIC in ROM. And, of course, .NET already brings Visual Basic.NET!
-dZ.
Hey, I heard that Windows isn't the only OS... (Score:5, Insightful)
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.
Re:BTDT (Score:5, Insightful)
*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.
That's exactly it (Score:4, Funny)
Guy reminds me of an old joke.
What's the difference between a bitch and a whore?
A whore fucks everyone. A bitch fucks everyone but you.
Re: (Score:3, Funny)
I remember those. We used to have to carry them around in the snow, uphill both ways. ;-)
Re: (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].
Re: (Score:3, Interesting)
You know that this is a repost of a 2002 slashdot article [slashdot.org]?
Re:BTDT (Score:4, Interesting)
"Single instance only" applied to all code - applications, libraries and OS. We often used to have 16 users on an 11/70 with 1MW of memory (ie 2MB) - all running the same program, so only one copy was resident. (or one of us was running the C or Fortran compilers :-)
isn't that how the BSDs do it today?
In RSX/11, programs could be "installed" so that they made their location on disk known to the OS, so when you ran a program, it was not necessary to search the file system for it. The location on disk, and offset to the entry point, was already known. A program could have multiple entry points (like grep, egrep etc), and libraries just used this mechanism. The dynamic linker stored the program (library) name and index into a table of entry points. I think early implementations statically linked the code to hack this stuff, before it became part of the OS.
If the search of the program you asked for found nothing, then the directories were searched. It was laziness of the users that meant the default strategy was used for most applications. I think VMS continued to support the install option, but I cant remember. I don't think Un*x ever did.
Programs only loaded the pages that were in use, and pages not in use were eventually swapped out. So huge programs did not take for ever to load - you loaded the first page, and jumped to it - then loaded which ever pages execution went to - so you did not need to spend years designing overlay strategies! This was possible because pages could load anywhere - the PDP11 supported "position independent code" (All modern 16 and 32 bit processors could still do this).
Don't you young people know anything? I know this, and I didn't even do computer science in college!
Get off my lawn.
Re:BTDT (Score:4, Interesting)
I think VMS continued to support the install option, but I cant remember. I don't think Un*x ever did.
IIRC install in VMS was to register a privileged library with the OS. A library like that could do stuff the calling process couldn't do. Most likely it was install image.obj/priv=sysprv,setprv and so on.
My experience with RSX was with a traffic signal application called SCATS. I once interviewed for a job in a hospital where they supported ~60 users on a single machine, probably an 11/84.
Our SCATS systems had up to 16 DZ11 MUX cards for 128 serial lines. I have never seen a system which could handle that many interrupts and run so cool in the sense that it was always responsive regardless of load and it would chug away for years without showing any signs of stress.
BSD is as close as you would get to that with modern systems. Maybe QNX though I haven't worked with that OS.
Re: (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
Re:BTDT (Score:4, Interesting)
Was that in RSX11-M?
Version 6 UNIX. I didn't abuse a.out as badly as this example abuses elf, though.
Really, with a.out, it wasn't abuse. That format LIKED these kinds of games. When I was hacking in Forth I wrote a "snapshot" word that did something like
Where patch-to-executable took advantage of the fact that an a.out was basically a core dump with some extra segments... and you could leave those segments off if you needed to. :)
I did some nasty stuff on RSX-11, though. Portable file and terminal I/O was a pain in the butt, because text files were variant record files with each line having a count and a length and a record/line type field and IIRC occasional block alignment issues, so to read and write text files in Forth I had a FORTRAN main that called Forth through an assembly glue routine, then called back to FORTRAN for textfile I/O. Also got tired of FORTRAN formatted I/O so I wrote a version of sprintf for my RATFOR code that used assembly glue to implement varargs in FORTRAN. Ah, the good old days...
Missing the point (Score:5, Funny)
Interesting, but she does sort of sidestep the whole 'Hello World!' part of a hello world program.
29 bytes ! Beat that !!! (Score:5, Interesting)
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
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
Re:Missing the point (Score:5, Insightful)
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.
Re:Missing the point (Score:5, Interesting)
After reading the linked article, I thought underwhelmed. Then I read the second article referenced in the summary:
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html [muppetlabs.com]
Now, that was interesting!
The strange thing is that the summary seems to imply that both articles are related, which they are most definitely not. The first one seems to be written by a naive noob, who just discovered a nifty trick in gcc. The second one is written by a real Wizard, who shows you how to conjure up some arcane magic to make ELF your bitch.
-dZ.
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: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:Old news is VERY OLD (Score:4, Interesting)
Re: (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
Re: (Score:3, Funny)
... and I read it in 2002. On slashdot [slashdot.org].
Nice but? (Score:5, Insightful)
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?
Re:Nice but? (Score:5, Insightful)
Which is missing the point. Haven't you ever wondered what's really in that 11k of machine code, and what it actually does? We've gotten so insulated from the lower levels of our computers that we no longer really understand how they do something so basic as terminating their own execution. The article felt more to me like an expository attempt to shed light on some of the things that libc has to do for us, rather than practical advice on attempting to make our programs smaller.
Re:Nice but? (Score:4, Insightful)
Now, that is not to say the libraries should not be optimized. It makes economic sense to spend significant time on such code. Just look at MS Vista. But complaining that we unnecessary library code is sometimes included does not really solve any problems.
Re:Nice but? (Score:4, Insightful)
Well that's part of the REASON that programs have become "bloated." We have plenty of resources these days. RAM and HDD space is cheap. So, it doesn't make sense to spend time trying to wring every byte out of a program. If having a bit of bloat makes the program more portable, or easier to debug, or more resilient to attack or whatever it is probably worth while.
I'd much rather have a program that was 1MB larger than it needs to be, but easy for the devs to maintain and nice and compatible than one that is as small as possible but is a complete mess at the code level. As a practical matter program data, like graphics, sounds, media, etc, is way, WAY bigger than the program itself. For example Mass Effect 2 has about 25.6MB of code between its binary and various DLLs. If you count system DDLs it uses, it is maybe up to 50MB. It's total size? 12.1GB. All the rest is data of various kinds. They could halve the size of the code and still not make even a tiny dent in disk or memory usage.
I can code that app in... (Score:5, Funny)
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?
Re:I can code that app in... (Score:5, Insightful)
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?
+5, Insightful (Score:5, Insightful)
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.
Re:I can code that app in... (Score:4, Funny)
Re: (Score:3, Insightful)
So did the original - it was launched from the command prompt and the shell was used for the output of the return code. The shell is part of the base OS anyhow, and you can't boot Linux without the shell.
Umm, but (Score:5, Insightful)
Since when does a Hello World program not actually output anything?
Re: (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".
If it's so simple, (Score:5, Insightful)
Similarly (Score:3, Interesting)
IEFBR14 (Score:5, Interesting)
Mainframers have been using this most simple of all utilities for decades - literally. The Wikipedia entry on it has a good write-up about this (literal) do-nothing program. It's whole purpose is to provide a mechanisim to to exploit the various functions contained in JCL to create, delete, and otherwise manipulate datasets on mainframes.
The wikipedia entry is here: http://en.wikipedia.org/wiki/IEFBR14 [wikipedia.org]
Re: (Score:3, Interesting)
Simpler "Hello World" in C? (Score:5, Insightful)
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?
Re:Simpler "Hello World" in C? (Score:4, Interesting)
char*_="Hello world.\n";
That is it - the whole program.
Re: (Score:3, Informative)
That is it - the whole program.
Doesn't say "Hello" to me!
Re:Simpler "Hello World" in C? (Score:4, Interesting)
But missed the point: http://www2.latech.edu/~acm/helloworld/c.html [latech.edu]
"This program is (supposedly) the smallest C program able to print "Hello world.". The compilation itself produces the desired printout and the program need not be actually run."
Still written (mostly) in C. . . (Score:3, Interesting)
"At the end, the code was assembler"
But, the key point is that the user didn't generate that assembly. The user wrote a C program (granted, the program doesn't actually do any output - it just stores a string in memory, then exits). The user called the compiler to compile the program. The user then *disassembled* the object code which was created by *the compiler*. So, the assembly you see was generated (indirectly, via the objdump command), by the C compiler.
Exception: the user did create a small assembly
Something similar (Score:3, Interesting)
I had a laptop that was really short on memory back in 1996 or so. I liked having the six virtual consoles, but rarely used them, so I wrote a program that would wait for you to press enter, then exec the regular login program. It copied the executable onto the same page as the stack and had no globals, so at run time, it used exactly one page of RAM. I used the same technique as the author here of calling syscalls directly instead of using libc.
YES!!!! FINALLY (Score:5, Funny)
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.
Re: (Score:3, Funny)
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.
No it won't. Do not be foolishly optimistic. Until videogames are readily available on Linux (and I mean commercial games like Call of Duty), no general consumer would be compelled to use Linux on Desktop (may not apply for netbooks).
*sigh*
Stoner code. (Score:4, Funny)
OK, when I first read this, I thought to myself, "now why in the hell would anyone care to do this?"
Then it dawned on me. One stoned programmer said to another....Yeah, that's probably how it went down. Both now, and back in 1979, when you could still smoke in the Data Center...
C++ is worse (Score:5, Insightful)
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.
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).
Re: (Score:3, Insightful)
There's utilities you can run to pull unused object code out of yo
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: (Score:3, Interesting)
I wasn't blessed with a color card. And I'm sure that's not actually any real dialect of assembly, but you get the picture.
Bare metal DOS? (Score:4, Insightful)
If you're actually programming on "bare metal", you're not really using DOS, are you? After all, DOS is an operating system -- a layer between your code and the hardware.
Did similar back in MS-DOS 2.11 (Score:5, Interesting)
Back in the early 1980s, I was doing development on MS-DOS 2.11 - the first real working version of MS-DOS that resembled Xenix more than CP/M.
I was using a combination of Lattice C and assembly language to do my day job. But I was upset about the libc bloat that Lattice C would drag into the program. Over the Christmas break, I sat down and wrote a tiny version of libc, with the 60% of the calls I actually used. Most of them were either thin wrappers on top of MS-DOS Int21 calls, assembly language implementations (the string functions), or reduced functionality (printf didn't handle strange alignments, floats or doubles), and custom startup/exit code. I also structured the library so that the linker would only link in functions that were actually used. For simple executables, I saw the on-disk file size drop from 10KB-20KB down to 400-600 bytes. Another thing that reduced on-disk file size was to create .com programs, rather than .exe programs.
I was also writing the handful of unix commands that I couldn't do without (ls, cat, cut, paste, grep, fgrep, etc). Since I was implementing dozens of Unix commands, each statically linked to libc, it was very important to reduce the over-all size of each executable. Most of the smaller trivial commands were less than 1KB in size. I think the largest was 4KB. I also had an emacs clone* that was 36KB when compiled and linked against my tiny lib.
For the longest time, I carried around a bootable MS-DOS 2.11 floppy, with my dozens of Unix commands, an emacs-like editor, Lattice C compiler, tiny libc, and some core MS-DOS programs. It allowed my to have my entire development environment on a floppy that I could stick in anyone's machine and make it usable.
* We had a source license for Mince, orphaned by Mark of the Unicorn, a tiny emacs-clone that ran on CP/M, MS-DOS, and Unix. We had enhanced it significantly.
Re: (Score:3, Interesting)
I've always wondered: what was the difference, in DOS, between a .com and a .exe?
Re:Hello World (Score:5, Funny)
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.
Re:Hello World (Score:5, Funny)
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".
And so he should! (Score:3, Funny)
"Hello World" uses over 90% of his "iHello World" work. You would be hard pressed to make a fair use argument here. ;-)
Re:11k Is Too Big? (Score:5, Insightful)
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?
Re:11k Is Too Big? (Score:5, Insightful)
But my stupid build process that generates the bloated Hello World is much more maintainable. Now get off my lawn.
Re:11k Is Too Big? (Score:5, Insightful)
Re:11k Is Too Big? (Score:4, Insightful)
/rant
Re:11k Is Too Big? (Score:4, Interesting)
Re:11k Is Too Big? (Score:4, Interesting)
...besides, high-level programmers often underestimate just how big a sector embedded programming is. The $IDIOTS_PET_LANGUAGE is for a PC. Now get me more RAM and better CPU for all the devices running embedded software, that are in my sight range as I look around:
- my cell phone.
- 6 different monitors (OSD doesn't happen magically. Something remembers the settings...)
- a videoserver
- 2 cheap switches
- a regulated power supply
- a heat-controlled soldering iron
- a regular phone
- 3 PC keyboards (hey, neither PS2 nor USB protocols happen by themselves)
- 3 computer mice (optical, meaning pretty advanced image analysis)
- my hand watch
- a battery charger
- a USB hub
- a security motion sensor
- an MP3 player
- a webcam
- a multimeter
- a car alarm remote
- a pendrive.
These all were programmed either in VHDL, Asembler, or C. The phone has some J2ME code too. Think of upgrading each of these devices so much that its firmware could be rewritten in, say, Perl. Or C#.
Also, think about how much embedded programming is in every PC. Each device controller has its own firmware... my bet is any average house contains more embedded programs (in embedded devices) than PC applications on the "family PC" and stored on media.
High-level programming languages are nice and have their place, but considering embedded "a niche not worthy of attention" is a bad mistake. The proportions between amounts of server:desktop:embedded software are much closer to 1:1:1 than most "high-level" programmers are willing to admit.
Re:11k Is Too Big? (Score:5, Funny)
My God, are you saying that people should use the right tools and techniques for the job at hand, rather than applying the same limited ones to every problem they come across?
Re:11k Is Too Big? (Score:4, Insightful)
Re:11k Is Too Big? (Score:5, Insightful)
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.
Re:11k Is Too Big? (Score:5, Insightful)
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. :)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Indeed.
At 11kB each, my 1TB harddrive would only fit some 97 million programs.
Re:11k Is Too Big? (Score:5, Insightful)
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. =)
Re:11k Is Too Big? (Score:5, Insightful)
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. ;-)
Re:11k Is Too Big? (Score:5, Interesting)
.equ SYSCALL, 0x80
.equ SYS_EXIT, 1
.equ SYS_WRITE, 4
.equ STDOUT, 1
.section
hello:
.ascii "hello world!\n"
.section
.globl _start
_start:
movb $SYS_WRITE, %al #put write syscall in eax
movb $STDOUT, %bl #set stream to stdout
movl $hello, %ecx #give address of start of buffer to print
movb $13, %dl #how many characters of buffer to print
int $SYSCALL
movb $SYS_EXIT, %al
int $SYSCALL
The above is a tiny hello world program i wrote myself, it's worth noting that even the resulting binary is larger than it needs to be, I wound up with a 133 byte binary by moving the text string into the ELF header via hex editor, and changing the instruction data to point to the new addresses.
Kind of hard to get it smaller than that while keeping it in ELF format, considering the actual object code in the binary was something like 15 bytes with the data illegally in the header.
The summary headline is crap (Score:5, Informative)
Re: (Score:3, Informative)
Re:11k Is Too Big? (Score:4, Insightful)
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:11k Is Too Big? (Score:4, Informative)
Re: (Score:3, Insightful)
OOP makes people lazy and gives them less of an understanding of what's actually going on.
All that OOP code you write gets translated back into something procedural, you know.
Re: (Score:3, Insightful)
I've noticed that people who critise OOP rarely understand what it is and tend to think it's tied to a particular type of language. OO is a way of thinking about a problem at a higher level than functional decomposition. You can code an OO solution in whatever language you like. Done properly it leads to elegant solutions eg; many of the examples in K&R exhibit the features of OO design and they were created b
Re: (Score:3, Insightful)
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:5, Interesting)
"An 11k app is not going to make me, or my computer, say 'Good Bye World'"
It is if your computer is a 38-cent Atmel AVR tiny 10, which only has enough space for 512 12-bit instruction words. This chip is about half the size of a sunflower seed, but is faster, and, in several ways, more powerful, than the original $5000 IBM PC from 1981.
Get away from the idea of Gigahertz desktops and $1000 laptops and join the real computer revolution!
For me, if it costs more that $5, it's not a computer that I take seriously. It's just a 20th-century digital processing appliance.
Re:11k Is Too Big? (Score:5, Funny)
You're right! I'm going to throw my laptop out the windows right now! Reading slashdot will be so much more fun on a computer smaller than a sunflower seed.
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.
Let the lawn derby begin (Score:4, Funny)
One of the earliest processors I used had only 256 bits of RAM (Yes, that's right 256 B I T S of memory)
Re: (Score:3, Funny)
One of the earliest machines I learned programming on only had 256 bytes of memory.
You lucky bastard.
My parents could never afford such computer. I had to learn programming on a computer with only 1 bit of memory (Yes that's right: 1 B I T of memory!)
Those were the days. And you tell the kids these stories and they won't believe you...
Re:Occams Wedge (Score:5, Insightful)
Re: (Score:3, Insightful)
That is what I said.
That is not a question for which a single good answer can be given, other than "it depends." There are so many variables. Just how often will how many processors do extra work (that will allow you to calculate the lost electricity - it is a real and calculable cost.) RAM usage also has real costs associated, including electricity, but calculating the final price tag is far more compl
Re:So what? (Score:5, Insightful)
Comment removed (Score:4, Insightful)
Re: (Score:3, Insightful)
When even modern processors have single megabytes of L3 cache, and less L2/L1 cache - it will make a difference if you're swapping from that to RAM constantly.
Re: (Score:3, Insightful)
It will be completely unnoticeable, even if you had a stopwatch.
Not only is this easy to see theoretically, as most programs will spend the bulk of their CPU time in tight loops, which obviously will be cached the first run through... but it's also easy to see in practice, for example, when processor performance with different cache sizes is compared.
Multitasking is probably one of the worst things imagineable for processor caches, yet even with 1000's of context switches every second the difference between
Re:So what? (Score:5, Insightful)
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.