| |||||||||||||
|
| |||||||||||||
What's that "GNU/Linux" in the beginning?What's that "GNU/Linux" in the beginning?Posted Dec 31, 2006 3:36 UTC (Sun) by landley (guest, #6789)In reply to: What's that "GNU/Linux" in the beginning? by zotz Parent article: The Ultimate Distro (Linux Journal)
> I have not considered this issue in a good long while now, but are there
I'm working on one. Firmware Linux (http://landley.net/code/firmware).
Currently, building it still requires four gnu packages (gcc, binutils,
By the way: Linux came out of the Minix development community, not the GNU
Rob
(Log in to post comments)
What's that "GNU/Linux" in the beginning? Posted Dec 31, 2006 14:11 UTC (Sun) by gnb (subscriber, #5132) [Link] I'm curious: is tcc really a plausible gcc replacement? Having worked onsystems 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.
What's that "GNU/Linux" in the beginning? Posted Jan 4, 2007 20:37 UTC (Thu) by dwheeler (guest, #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 (guest, #6789) [Link] I've got my own mercurial repository which has turned into a semi-fork:
But I've got too many other things going on to want to become the
And it does do a little optimization, simple constant propogation and
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 (guest, #6789) [Link] The gcc build system sucks rocks, I've just learned where to hit it witha large stick.
A compiler is a program to turn input files into output files. It takes
If compiling the docbook to PDF converter cared a lot whether it was
The difference between a cross compiler and a native compiler is hugely
If the current gcc build system is a distinct improvement over what came
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 (guest, #6789) [Link] The tradeoff here is do I want to include 35 megabytes of gcc/binutils tobuild "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
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.)
What's that "GNU/Linux" in the beginning? Posted Dec 31, 2006 22:51 UTC (Sun) by Arker (guest, #14205) [Link] Linux was built using Minix and GNU at the start. The use of Minix to bootstrap the project ended very quickly however.
I was using GNU/HPUX before I ever heard of Linux. When I found Slackware, I no longer had to beg for access to the math departments HP boxes, I could run GNU on a cheap 386 at home. Of course working with boxes of floppies and downloading all week on a dialup SLIP connection (yes, PPP came later) was a pain in the butt, but it was well worth it.
Don't tell me I'm not running GNU/Linux, I know better.
What's that "GNU/Linux" in the beginning? Posted Jan 1, 2007 15:35 UTC (Mon) by grouch (guest, #27289) [Link] It might be appropriate here to mention an older work:
What's that "GNU/Linux" in the beginning? Posted Jan 5, 2007 20:13 UTC (Fri) by landley (guest, #6789) [Link] Interesting juxtaposition, but the connection he's trying to suggest byit isn't really there. "Just for Fun" goes into a lot more detail, such as the fact that the system call reference he used to implement his system call list was the SunOS manuals in his university library. (And nobody calls it Sun/Linux.) The working Unix systems he had lying around were Minix and the university's MicroVax he dialed into to access the internet. (And you'll notice Linux grew out of his terminal program for dialing into that MicroVax, he wrote the term program to boot from a floppy because Minix's serial handling couldn't even keep up with 2400 baud without dropping characters, and he had to take over all the hardware himself to get his home PC to talk to the university machine.)
You might also want to read the first year of the linux kernel
http://landley.net/history/mirror/linux/1991.html
What packages are mentioned? Several minix files, the mtools package
Kernel development being driven by running real applications doesn't have
Rob
|
|
||||||||||||