The really interesting part is the discussion of optimizations:
> Consider this example raised by Linus: the compiler might look at how the kernel accesses page table entries and notice that no code ever sets the "page dirty" bit. It might then conclude that any tests against that bit could simply be optimized out. But that bit can change; it's just that the hardware makes the change, not the kernel code. So any optimizations made based on the notion that the compiler can "prove" that bit will never be set will lead to bad things. Linus concluded: "Any optimization that tries to prove anything from more than local state is by definition broken, because it assumes that everything is described by the program."
Programmers tend to assume that optimization is transparent--code will work the same regardless. But that's not really true, and as Linus's example demonstrates, compiler writers and compiler users may have different ideas of what the compiler is allowed to assume. And there isn't an obvious line to be drawn regarding safe and unsafe assumptions either.
I think the lesson is - if you're going to write a kernel, you also need to write your own compiler, and that leads you to writing your own language too.
I don't think that's the lesson at all. If you write a kernel you'll have to write some assembly. If you really want you can write your own compiler that writes the assembly you need I suppose, but you're still writing the assembly somewhere, or at least aware of exactly what assembly will be omitted. The point of something like C11 atomics is that you don't want to have to know the assembly. In the kernel you don't have that luxury
It's funny how C and C++ standard names are not Y2K compliant. Are the committees so confident the languages won't be around in 80-100 years from now? :) I wouldn't be so sure.
> Consider this example raised by Linus: the compiler might look at how the kernel accesses page table entries and notice that no code ever sets the "page dirty" bit. It might then conclude that any tests against that bit could simply be optimized out. But that bit can change; it's just that the hardware makes the change, not the kernel code. So any optimizations made based on the notion that the compiler can "prove" that bit will never be set will lead to bad things. Linus concluded: "Any optimization that tries to prove anything from more than local state is by definition broken, because it assumes that everything is described by the program."
Programmers tend to assume that optimization is transparent--code will work the same regardless. But that's not really true, and as Linus's example demonstrates, compiler writers and compiler users may have different ideas of what the compiler is allowed to assume. And there isn't an obvious line to be drawn regarding safe and unsafe assumptions either.