TCCBOOT Compiles And Boots Linux In 15 Seconds

An anonymous reader writes "TCCBOOT is the first boot loader able to compile and boot a Linux kernel directly from its source code. It can compile and start booting a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4. TCCBOOT uses the latest version of the TinyCC C compiler."

Not a complete compile

[cbreaker]

The README says it needs some of the binaries and headers on the linux kernel, so you have to pre-compile these first.

I guess this could have some limited use somewhere, perhaps, but I can't really see how if you need some precompiled stuff.

Architecture Independence

[Ford Prefect]

For some reason, I'm reminded of the platform-independent device drivers and boot code written in Forth in Open Firmware [openfirmware.org].

I don't know how useful a processor architecture-independent version of this would be (the compiler itself is pre-compiled for a specific processor, presumably!) but it does seem a rather cool hack. Maybe an ultra-inclusive version of Gentoo?

Re:usefulness?

[Anonymous Coward]

It's called a "hack".

Have the last nerd left the building?

Wha?

[stratjakt]

It takes a couple minutes to compile my kernel on a 3.06 P4, and of course, forever and a day to boot.

I guess 15 seconds is to compile without any device support other than the boot drive.

That said, linux boot time as it is sucks, especially if you want to use it on something like a router/firewall box like I do. The only button I ever press on that machine is reset. VPN not working? Reset.

That's how it should work IMO, but every time I do it the 'net is out for 10 mintues until it's back up.

Resetting the whole box should be faster than ssh'ing in and typing a "/etc/init.d/shorewall restart" and "/etc/init.d/openvpn restart".

Re:How?

[vidarh]

TCC is an incredibly tiny compiler with practically no dependencies on the environment. It's based on a cleaned up entry to the obfuscated C contest. So you can safely assume it's using every dirty trick in the book and then some. It still sounds incredible though.

Blatant Karma Whoring: In case of a slashdotting..

[jimicus]

Introduction
TCCBOOT is a boot loader able to compile and boot a Linux kernel directly from its source code.

TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4.

TCCBOOT is based on the TinyCC compiler, assembler and linker. TinyCC is an experiment to produce a very small and simple C compiler compatible with the GNU C compiler and binary utilities.
Screenshots
Download
ISO image demonstation: tccboot.iso (5.9 MB).

Create a CD from it and boot it to see TCCBOOT in action (PC with at least 64 MB of RAM required). You can also try it with the QEMU PC emulator.

TCCBOOT source code: tccboot-0.1.tar.gz, and README file.

Re:script?

[Alioth]

It should never need a kernel compile (I'll make an exception for an experimental driver) - they should all compile fine as modules. All the most recent 3rd party Linux drivers I've used just needed the module compiling and then loading - not even a reboot was needed.

Re:How?

[maxwell demon]

Non-optimizing compilers can be very fast. Basically you just have to parse it and output pre-defined asm for each bit. According to this page [borland.com], Turbo C 2.01 (a 1989 product) compiles over 16,000 lines per minute. Given that this number is also on the advertisement shown in that picture, which is actually from that time, it's 16,000 lines on the hardware of that time (i.e. 386). Now IIRC the 386 had at most 33MHz, so from the clock speed difference alone, on an 2.4GHz computer it should compile about 1.16 million lines per second; assuming a factor 4 in efficiency (i.e. modern processors can do 4 times as much per clock cycle as an 386), it should be possible to compile the same amount in 15 seconds. Now according to this page [dwheeler.com] the Linux kernel has 1,526,722 lines of code, so if either my efficiency factor of 4 was too low, or TCC can compile about 1.5 times as fast as Turbo C 2.0 could (or maybe a combination of both), it's clearly not that far-fetched that a linux kernel could be compiled in 15 seconds.

LinuxBIOS

[hey]

If you want a more sensible Linux-specific
BIOS there's the LinuxBIOS [linuxbios.org].
It looks like its only for clusters but I'd
like to get it from my next Linux box.

Re:But why?

[rillian]

It is indeed very fast, but it wouldn't compile ghostscript for me.

# apt-get install tcc
[...]
$ cd ~/projects/ghostscript/gs
$ make distclean
[...]
$ CC=tcc ./configure && make
[...]
tcc -DHAVE_MKSTEMP -DHAVE_HYPOT -O -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -I./src -I./obj -I./obj -I./src -o ./obj/zfcid.o -c ./src/zfcid.c
In file included from ./src/zfcid.c:23:
In file included from ./src/bfont.h:24:
./src/ifont.h:34: identifier expected
make: *** [obj/zfcid.o] Error 1

Compiler bug?

I also like how it has an auto-run switch to invoke the compiler output. So you can make C source executable from the command line by putting #!/usr/bin/tcc -run at the top. I would use that for quick test programs in C. Once it's debugged you can run it through gcc.

Re:TCC compiler

[TheRaven64]

TCC has a few significant drawbacks.

1. It is not portable (well, technically it is portable, but currently only has an i386 back end).
2. It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
3. It produces fairly sub-optimal code. The register allocation done by TCC is not very clever, and it performs no serious optimisation steps.

On the other hand, TCC has two huge advantages:

1. It is not GCC. Compiling your code using two or more compilers and ideally for 2 or more CPU architectures is a good way of finding some more obscure bugs.
2. It is very fast. The less time you spend compiling, the more time you can spend testing / debugging.

Tcc seems truly amazing

[herve_masson]

I don't care much if my kernel boots from freshly compiled source code or from my last build, but this tcc thing is really incredible.

I had to download its source code, build it and use it to believe it. 100k for something that compile a C code about 5 times faster (my very rough measures) is something I would have consider a joke if I could not see it in action.

Obviously, it probably not do all the optimizations gcc implements, but still. Wow.

Re:How?

[LiENUS]

Actually the TinyCC site lists a speedchart at http://fabrice.bellard.free.fr/tcc/#speed [bellard.free.fr] measurements are done on a 500 MHz K6. That should give you a better idea than just estimating based on Turbo C 2.0

Re:Too fast...

[Bun]

If you're having trouble with a service, and it's started through init.d (which it probably is, if you're using Mandrake or Fedora/RedHat), then simply restart the offending service. So, add this to your list of steps:

1a) /etc/rc.d/init.d/servicename restart

Note that your init scripts might be in a slightly different location.

Re:usefulness?

[hal-j]

Run this in your root (and other important directories):

echo "" > -i

You'll thank me if you do something stupid like that again. The "-i" will be seen as an argument to /bin/rm, and it'll ask you to confirm each item. Sure, this could be a pain in the ass, but I can't think of a good reason to "rm *" in an important directory like that.

Re:Too fast...

[marcansoft]

Since I'm using Gentoo on an AMD64, which even on its stable flavour is more "experimental", if X locks down hard and alt+sysRq+R (unRaw) doesn't let me switch VT, I usually alt+sysRq+E (tErm all tasks) or alt+sysRq+I (kIll all tasks).
I then have a simple script that removes all the lockfiles in /var/lib/init.d/started which correspond to actual daemons (faster than calling "zap" for all the initscripts) and then just "rc default". (or rc 5, or init 1; init 5, or whatever you can do on other distros to start everything that's stopped and should be started)

This usually fixes many problems quickly (just the sysrq, login, run the script, and then tell it to start everything again; you can continue using X and since KDE or Gnome will mostly be cached in RAM it will start fast.)

Re:Too fast...

[Slime-dogg]

I am not your average sysadmin who can figure out every script and knows much about process lists, or Kill Signals.

That's what an education is for. From this sentence, I get the impression that you are a sysadmin, albeit one that is grossly unqualified for any sysadmin position.

I guess we can pin this sort of thing on Microsoft, who's penchant for wizards and paperclips has led to a flooding of the market by uneducated or unqualified IT workers. It's the same frightful problem that the developer space deals with, where VB6 allows people to create executables without understanding programming at all.

I apologize, if I'm being offensive. It is frustrating to see the industry that I work in crumble because of the antics of a single company and the bloat in salaries a few years back. I'm not saying that you, in particular, have no chance of learning, it looks like you're interested in what you're doing... But there are quite a few more capable and qualified people out there without jobs that can fill a sysadmin position that is filled by an MS drone.

Imagine... if all sysadmins had CS degrees, the majority of all servers would probably be *NIX based, and Code Red wouldn't have happened.

Re:Too fast...

[pclminion]

/etc/rc.d/init.d/servicename restart

Heh, why do people type so much? On RedHat at least, there is a script in /sbin called "service" which runs the given service for you.

For example, instead of typing:

/etc/rc.d/init.d/httpd restart

You can just type:

service httpd restart

Less than perfect first impression

[dbrower]

So I download the source to my Suse 9.x machine with gcc 3.3.3, run configure:

./configure
Binary directory /usr/local/bin
Library directory /usr/local/lib
Include directory /usr/local/include
Manual directory /usr/local/man
Doc directory /usr/local/share/doc/tcc
Source path /home/dbrower/src/tcc-0.9.21
C compiler gcc
make make
CPU x86
Big Endian no
gprof enabled no
Creating config.mak and config.h
config.h is unchanged

say make and get a compilation error:

gcc -O2 -Wall -c -o bcheck.o bcheck.c
bcheck.c:172: error: conflicting types for `__bound_ptr_add'
bcheck.c:80: error: previous declaration of `__bound_ptr_add'
bcheck.c:231: error: conflicting types for `__bound_local_new'
bcheck.c:87: error: previous declaration of `__bound_local_new'
bcheck.c:247: error: conflicting types for `__bound_local_delete'
...

This is fixed by defining __TINYC__ in the rule for bcheck.o, and you get a tcc executable. Trying to remake it with itself

rm *.o
make CC=tcc

Results in complaints about stddef.h not found. Adding -I/usr/include/linux leaves us with other errors, and as Mr. Costello would say at this point, "I don't give a darn".

My interest just ran dry for now.

-dB, on third base.

Re:But why?

[pclminion]

Compiler bug?

Why not give some more information so we can figure out why it doesn't work? It could just be a misconfigured #define somewhere.

Re:Too fast...

[Fweeky]

Why bloat / with a script when you can do:

alias service /etc/rc.d/init.d/!*

?

Re:How?

[Anonymous Coward]

Yes the otcc entry to the ioccc was the beginnings, but the compiler it'self grew out of Fabrice Bellard wanting an ISOC99 compiler that was faster than gcc and other compilers on the market. And well damnit, he did it, it's a beautiful compiler, and the only compiler in the world AFAIK that will let you avoid the compile step in the development process by putting for example #!/usr/bin/tcc -L/usr/lib/python23 -lpython23 as your first line and let it do the compile execute process without dumping the binary. That believe it or not has come in handy for quicker devel time. At least for me.