

Custom compiler for Linux kernel? It could happen - epall
http://lkml.org/lkml/2009/4/22/78

======
SwellJoe
There have been briefly existent gcc forks in the past, specifically for
kernel compilation on various distros.

I suspect there probably will come a time when gcc is replaced. Possibly by an
LLVM compiler like clang. But, the likelihood of a from-scratch C compiler
just for the kernel seems very low, to me. Yes, the kernel developers could do
it. And, yes, Ingo is one of the most productive developers in the world, and
if he got it into his head to make such a thing happen (despite the general
mood of the community being against such an idea), he could probably do a
large percentage of it on his own. But, it's just a very large undertaking,
and the things that we all find irritating about gcc are often the things that
make it suitable for so many situations and architectures (edge cases are ugly
but necessary when talking about supporting huge numbers of architectures).

------
derefr
If they're going to write their own compiler/linker/assembler suite, why even
bother remaining compatible with C? Why not just create a specifically-
optimized "kernel-ese" DSL?

~~~
scott_s
But that's what C _is_.

edit: my argument can be summarized in sections 1 and 2 in an essay I wrote
for a class a year ago:
<http://people.cs.vt.edu/~scschnei/ece5530/languages.pdf>

~~~
wmf
OTOH several other OS projects have their own DSLs: Oberon, Vault, BitC, and
Sing#.

~~~
scott_s
I think we're abusing the title "Domain Specific Language." I'm only familiar
with BitC and Sing# on that list, but I call those _systems programming
languages_. Granted, one could consider systems programming the domain, but
since systems programming is so ubiquitous in computing and for a long time
that was the only kind of programming, I think it's inaccurate to call those
DSLs.

Anyway, with the exception of Oberon, the others are still research projects.
I don't think a research language is appropriate for implementing the Linux
kernel.

I do hope that in the future, something as important as the Linux kernel is
implemented with a modern systems programming language - it would indicate
progress - but Linux is an immediate need.

------
DanHulton
Well, actually if you follow the comment thread - it's not really likely. Most
folk are clamoring about how poor an idea this is.

------
anthonyrubin
<http://wiki.freebsd.org/BuildingFreeBSDWithClang>

~~~
jballanc
It's worth noting that Clang is being primarily used with the Mach kernel
which is heavily influenced by BSD. I don't know enough of the specifics to
say whether or not this would make compiling FreBSD easier than the Linux
kernel, but I suspect it might.

~~~
gecko
Actually, Mach and BSD have bupkis in common. It simply so happens that OS X
uses a reasonable amount of BSD user-land code in OS X to make compatibility
easier. This probably makes porting FreeBSD to clang easier indirectly--the
user-land tools and libraries from the BSDs are written in the same style as
the kernel, and so supporting them likely makes supporting the kernel easier
that much easier--but saying Mach is similar to BSD is like saying Windows NT
is similar to DOS simply because it can run DOS programs.

~~~
ankhmoop
You're technically correct in regards to Mach, but in the context of Mac OS X
a very large percentage of the kernel is composed of BSD-derived code.

Unfortunately, none of this is particularly relevant to clang, as the kernel
design (in respect to Mach or BSD) really has little bearing on its
compiliability.

[Edit]

I'm very surprised that this was downvoted to 0. The discussion was in context
of Mac OS X, and the technical veracity is easily confirmed:

<http://en.wikipedia.org/wiki/Xnu>
<http://fxr.watson.org/fxr/source/bsd/?v=xnu-1228>

------
andr
Whatever the case, it would be significantly easier to correct GCC's
shortcomings instead of starting afresh (and facing all those shortcomings,
and others, again).

~~~
Andys
Have you ever looked at the source of GCC? :-)

------
Ennis
I remember coding together a compiler using flex and bison. It was a
nightmare. This definitely is not a short term task. Frankly I don't think the
commitment is there from the community. Not yet at least.

Then again, gcc breakage is ridiculously common. It's got to be tackled at
some point.

~~~
barrkel
Flex and bison? See, that's a mistake right there! The tools often end up more
hassle than coding the lexer and parser directly.

Writing compilers is normally fun, not a nightmare. It does tend towards
nightmarish if your implementation language is very low-level, though;
particularly if it lacks type safety and garbage collection.

