No, this is being worked in. The goal should be a -Oboring optimizer without any broken optimizations and aggressive UB assumptions. Something neither gcc nor clang can provide.
you cannot, as linux code is using a lot of gcc/clang extensions stuff, namely this is some sort of C dialect, not really C.
Almost at every new release of linux, "somebody" did manage to commit into its code the usage of new gcc/clang extensions.
The right(TM) way would be to port linux to simple and lean C (like some simple C89 with benign bits of c99/c11): the price is some loss of performance which could be partially mitigated with an assembly port of critical fast-paths (I guess that would show on really loaded servers only).
In the end, if RISC-V is a success, namely a world with a pertinent ISA without toxic IP tied to it (like x86/arm), then a full assembly port of linux would be more than interesting in order to rid it from compiler tantrums.
Yes, but beyond that qemu was pretty much fabrice nerdsniping himself: he initially wanted to make the tcc backend more flexible (to support other targets than x86), then started playing with making the frontend more flexible, at one point he started to make the frontend take in compiled machine code, and that's the starting point of qemu: a dynamic recompiler / machine code translator, rather than a traditional emulator.
You're right, sorry, I'm not yet used to the HN netiquette. I did specify the kernel version in the title, because the program really can't compile newer kernels. It seems I can't fix the title now. Please flag the OP, after all it would be better to link to the original bellard's site instead of this github repository.
You could take this one step further and have some magic filesystem filter such that all binaries are compiled before use. Ie. your hard disk would contain no executable code, only source code.
It sounds slow, but it needn't be if you have the right caching in place. Binaries could even be recompiled with better/slower compilers as needed to give better performance too.
Now I think about it it isn't so different from the android/java model of shipping applications as bytecode...
I guess that's the logical extreme of what Gentoo is doing, just without the speed benefits (since the compiler is under time pressure and thus won't do a great job). Maybe if you combine it with profile guided optimization? (Yes, this is basically reinventing Java/.NET)
tcc has a -run option argument which executes the binary after creating it as a temporary file. This way tcc -run can be specified in the shebang and you can execute c code like a script, which is outright amazing.
21 comments
[ 3.4 ms ] story [ 56.7 ms ] threadhttps://bellard.org/tcc/tccboot.html
If you take a modern kernel (like 5.x) and build configure it with 'make tinyconfig', it should build similarly quickly.
https://bootstrappable.org/
https://bootstrapping.miraheze.org/wiki/Mes
https://reproducible-builds.org/
https://archive.fosdem.org/2021/schedule/event/gnumes/
The right(TM) way would be to port linux to simple and lean C (like some simple C89 with benign bits of c99/c11): the price is some loss of performance which could be partially mitigated with an assembly port of critical fast-paths (I guess that would show on really loaded servers only).
In the end, if RISC-V is a success, namely a world with a pertinent ISA without toxic IP tied to it (like x86/arm), then a full assembly port of linux would be more than interesting in order to rid it from compiler tantrums.
Linux 5.x kernel that is, but not Linux 4.x kernel because that was tcc-compilable?
It sounds slow, but it needn't be if you have the right caching in place. Binaries could even be recompiled with better/slower compilers as needed to give better performance too.
Now I think about it it isn't so different from the android/java model of shipping applications as bytecode...