Posted by
timothy
on from the count-to-ten-very-slowly dept.
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
by
cbreaker
·
· Score: 4, Informative
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.
-- - It's not the Macs I hate. It's Digg users. -
Architecture Independence
by
Ford+Prefect
·
· Score: 2, Informative
For some reason, I'm reminded of the platform-independent device drivers and boot code written in Forth in Open Firmware.
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?
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".
--
I don't need no instructions to know how to rock!!!!
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..
by
jimicus
·
· Score: 3, Informative
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.
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.
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, 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 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.
-- The Tao of math: The numbers you can count are not the real numbers.
If you want a more sensible Linux-specific BIOS there's the LinuxBIOS. It looks like its only for clusters but I'd like to get it from my next Linux box.
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
by
TheRaven64
·
· Score: 5, Informative
TCC has a few significant drawbacks.
It is not portable (well, technically it is portable, but currently only has an i386 back end).
It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
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:
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.
It is very fast. The less time you spend compiling, the more time you can spend testing / debugging.
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.
Actually the TinyCC site lists a speedchart at http://fabrice.bellard.free.fr/tcc/#speed measurements are done on a 500 MHz K6. That should give you a better idea than just estimating based on Turbo C 2.0
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.
-- "Anyone that has ever gotten an idea based on any of my work and done something better with it-good for you."--J.Carmack
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.
--
-Hal
Re:Too fast...
by
marcansoft
·
· Score: 2, Informative
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...
by
Slime-dogg
·
· Score: 2, Informative
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.
-- You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Re:Too fast...
by
pclminion
·
· Score: 2, Informative
/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
by
dbrower
·
· Score: 2, Informative
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.
-- "It if was easy to do, we'd find someone cheaper than you to do it."
Re:But why?
by
pclminion
·
· Score: 2, Informative
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...
by
Fweeky
·
· Score: 2, Informative
Why bloat / with a script when you can do:
alias service/etc/rc.d/init.d/!*
?
Re:How?
by
Anonymous Coward
·
· Score: 1, Informative
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.
Slashdot Mirror
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.
- It's not the Macs I hate. It's Digg users. -
For some reason, I'm reminded of the platform-independent device drivers and boot code written in Forth in Open Firmware.
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?
Tedious Bloggy Stuff - hooray?
It's called a "hack".
Have the last nerd left the building?
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".
I don't need no instructions to know how to rock!!!!
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.
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.
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.
Oolite: Elite-like game. For Mac, Linux and Windows
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, 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 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.
The Tao of math: The numbers you can count are not the real numbers.
If you want a more sensible Linux-specific
BIOS there's the LinuxBIOS.
It looks like its only for clusters but I'd
like to get it from my next Linux box.
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
[...]
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
In file included from
In file included from
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.
- It is not portable (well, technically it is portable, but currently only has an i386 back end).
- It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
- 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:I am TheRaven on Soylent News
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.
Actually the TinyCC site lists a speedchart at http://fabrice.bellard.free.fr/tcc/#speed measurements are done on a 500 MHz K6. That should give you a better idea than just estimating based on Turbo C 2.0
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:
/etc/rc.d/init.d/servicename restart
1a)
Note that your init scripts might be in a slightly different location.
"Anyone that has ever gotten an idea based on any of my work and done something better with it-good for you."--J.Carmack
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.
-Hal
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). /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)
I then have a simple script that removes all the lockfiles in
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.)
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.
You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
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:
You can just type:
service httpd restart
This is fixed by defining __TINYC__ in the rule for bcheck.o, and you get a tcc executable. Trying to remake it with itself
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.
"It if was easy to do, we'd find someone cheaper than you to do it."
Why not give some more information so we can figure out why it doesn't work? It could just be a misconfigured #define somewhere.
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.