What's that "GNU/Linux" in the beginning? [LWN.net]

What's that "GNU/Linux" in the beginning?

Posted Dec 31, 2006 14:11 UTC (Sun) by gnb (subscriber, #5132)
In reply to: What's that "GNU/Linux" in the beginning? by landley
Parent article: The Ultimate Distro (Linux Journal)

I'm curious: is tcc really a plausible gcc replacement? Having worked on
systems that used gcc as a cross-compiler I'm aware that some of it,
particularly the build system, is "interesting" and it might be nice to
replace it, but a lot of work has gone into the gcc optimiser and last I
checked it seemed to generate pretty reasonable code (at least on ARM).
I'd guess a distribution called Firmware Linux is pretty size-conscious,
so optimisation quality must be a significant factor for you.

(Log in to post comments)

What's that "GNU/Linux" in the beginning?

Posted Jan 4, 2007 20:37 UTC (Thu) by dwheeler (subscriber, #1216) [Link]

tcc is quite usable, but it's not a gcc replacement. tcc parses the statements and nearly immediately generates assembly that implements that statement, with VERY little optimization. The good side: tcc compiles VERY quickly, in some cases 10x faster than gcc. Indeed, there's a demo "FASTBOOT" that boots the tcc compiler, which then compiles and runs the Linux code from source (!). The downside: tcc code runs VERY slowly compared to gcc-generated code. By design, tcc generates something that works, but it doesn't have any of the intermediate structures that make good optimization possible. Granted, tcc-generated code runs fast enough for many purposes. But most users NEVER compile programs, and constantly run them, so trading away run-time performance is often not worthwhile. That said, tcc is very good for some purposes. I used it for my work to counter the trusting trust attack. tcc had some bugs, and the primary developer isn't doing much maintenance of tcc (because he's busy with other projects like QEMU), which is another problem. I some others are doing some maintenance of tcc.

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:38 UTC (Fri) by landley (subscriber, #6789) [Link]

I've got my own mercurial repository which has turned into a semi-fork:

http://landley.net/hg/tinycc

But I've got too many other things going on to want to become the
project's new maintainer right now. The old maintainer (Fabrice) has his
hands full with QEMU.

And it does do a little optimization, simple constant propogation and
such. It wouldn't be that hard to shoehorn dead code elimination in
there, which makes it a lot more usable for things like the linux kernel
and busybox (where dead code elimination is relied on by the configure
system to avoid lots of hideous #ifdefs).

Getting the linker to garbage collect is a larger project...

What's that "GNU/Linux" in the beginning?

Posted Jan 9, 2007 17:20 UTC (Tue) by nix (subscriber, #2304) [Link]

Doing DCE properly requires a lot of dataflow analysis which would be really rather hard to ram into tcc (at least it would have been the last time I looked at it).

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 17:37 UTC (Fri) by nix (subscriber, #2304) [Link]

The build system is a good bit less 'interesting' than it used to be (although still quite hairy). (Not that GCC is devoid of cruft in other areas, of course...)

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:54 UTC (Fri) by landley (subscriber, #6789) [Link]

The gcc build system sucks rocks, I've just learned where to hit it with
a large stick.

A compiler is a program to turn input files into output files. It takes
multiple sources of input (c source, header files, libraries), but so
does a docbook to PDF converter that needs fonts or style sheets.
There's no fundamental difference between the two.

If compiling the docbook to PDF converter cared a lot whether it was
running on ARM or Mips or Sparc it would be broken and unportable. But
you can't configure gcc to say "build arm files" without telling it "and
you're running on i386" as if it makes a huge difference.

The difference between a cross compiler and a native compiler is hugely
artificial, and gcc's insistence on being told --host as well as --target
is stupid. The fact it can be told _three_ (--host, --target,
and --build) is just _crazy_. And its insistence that if --host
and --target are the same string then you're obviously not creating a
cross compiler, so build everything differently, is just _evil_. (Hello,
host has glibc, target has uClibc. The dynamically linked binaries
you're producing won't run on the host because uClibc isn't installed.
YOU ARE CROSS COMPILING.) One of the reasons I like tcc is that it
doesn't make a big deal about this: configure it to produce arm binaries,
build it _with_ a compiler that links it against uClibc, and it just
works. There doesn't have to be a special name for doing that ("canadian
cross") because it's NOT A BIG DEAL.

If the current gcc build system is a distinct improvement over what came
before, we are _beyond_ "damning with faint praise".

And don't get me started on its' path search logic.

What's that "GNU/Linux" in the beginning?

Posted Jan 9, 2007 17:34 UTC (Tue) by nix (subscriber, #2304) [Link]

The path search logic has just got a little cleaner :)

Of course it makes a difference what the build system is: it needs to know if the files it builds to incorporate into the (many) little-language code generators it builds and uses during the build process can also be linked into the final compiler binary. It needs to know if a three-stage bootstrap is even *possible* or whether `make' should invoke a one-stage build (`make bootstrap' is so 2004, y'know, it's just `make' like every other package these days). It needs to know if there are any differences between e.g. the floating-point representation used on the build and host system. It needs to know if it can run configure tests to determine properties of the host system, or whether it has to assume safe defaults (you wouldn't want it doing the latter in the common case). (tcc doesn't need to do this to such a degree because it doesn't come with a bunch of runtime libraries. Also it doesn't need to cater for the nest of snakes which is exception unwinding and the related nest which involves shared libraries, destructor invocation order, and so forth.)

And as for the distinction between a native and cross-compiler being artificial, well, in *theory* a compiler could be made that didn't care what its host system was, but in practice unless it is to be intolerably slow it *must* know the machine's native types at least (which varies between OS and platform because it is ABI-dictated, and on many platforms GCC/binutils do not set the ABI). (A sufficiently nonportable compiler could avoid paying attention to systems that don't have IEE754 floating point, but GCC is not that nonportable, or at least at one point it wasn't: I'm not sure how many non-IEEE754 systems are left. I think some are, discounting ia32/x87 of course with its horrible `extended precision' mess, which is slowly becoming legacy anyway as SEE fpmath takes over.)

The `target triplet' stuff GNU has got is a bit ugly, but if you consider it to be an `ABI-and-OS-and-core-libraries indicator' (which is basically what it is), then it makes a bit of sense. uClibc just needed a new target triplet/quadruplet (and, oh look, *-*-*-uclibc works perfectly well).

What's that "GNU/Linux" in the beginning?

Posted Jan 5, 2007 19:42 UTC (Fri) by landley (subscriber, #6789) [Link]

The tradeoff here is do I want to include 35 megabytes of gcc/binutils to
build "hello world", or do I want a 100k executable to do the same thing?
And if you ship a compiler that can't rebuild the system, it's not a real
compiler ("gcc 2.96/kgcc" for example).

Yes, the system is size conscious, but there's a lot of meanings for
that. (Install image, runtime memory, requirements of the system you
build it on...) Nice to have multiple options...

What's that "GNU/Linux" in the beginning?

Posted Jan 10, 2007 10:32 UTC (Wed) by nix (subscriber, #2304) [Link]

I'd agree that tcc is a good choice for a self-hosting embedded distro (although a lot of `embedded'/handheld-or-smaller systems these days could swallow most of a normal Linux distro without breaking a sweat, there are some systems that can't. Whether this will still be true when really large flash RAM chips become common is another matter.)