Re: What if?

From: Norbert van Nobelen
Date: Thu Dec 02 2004 - 01:39:57 EST


On Thursday 02 December 2004 05:40, Theodore Ts'o wrote:
> On Thu, Dec 02, 2004 at 05:34:08AM +0530, Imanpreet Singh Arora wrote:
> > I realize most of the unhappiness lies with C++ compilers being
> > slow. Also the fact that a lot of Hackers around here are a lot more
> > familiar with C, rather than C++. However other than that what are the
> > _implementation_ issues that you hackers might need to consider if it
> > were to be implemented in C++.
>
> The suckitude of C++ compilers is only part of the issues.
>
> > My question is regarding how will kernel
> > deal with C++ doing too much behind the back, Calling constructors,
> > templates exceptions and other. What are the possible issues of such an
> > approach while writing device drivers? What sort of modifications do
> > you reckon might be needed if such a move were to be made?
>
> The way the kernel will deal with C++ language being a complete
> disaster (where something as simple as "a = b + c + d +e" could
> involve a dozen or more memory allocations, implicit type conversions,
> and overloaded operators) is to not use it. Think about the words of
> wisdom from the movie Wargames: "The only way to win is not to play
> the game".

Let us do it all in assembler. Real optimization for every CPU.

BTW, that sparks a question:
Did anybody already do a benchmark to see what happens if you address an AMD
cpu not with x86 instructions but with it's native code, so to circumvent the
internal translation in the CPU?


>
> - Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/