More Of The Linux Kernel's x86 Assembly Code Gets Rewritten In C

[wizard69]

Am I the only once somewhat concerned? It's one thing to say, "this isn't needed" or "that was because..."... but when you pretty much say, "it's not clear what it's supposed to do"... so I removed it... you would think somebody could chime in with "the reasoning" behind it.... yes??

This is the problem with assembly code, if it isn't well structured and documented even the original programmer will have trouble understanding it. It is very possible that nobody really knew what was going on with the code.

[Marc Driftmeyer]

Who wrote the original code? Alan Cox?

[mr_tawan]

Although it might have a negative impact on the overall performance, I think moving away from ASM to C would benefit in the long run. This is a good news indeed.

[mlau]

and no, compilers still don't match the performance of what an average assembly programmer can write
so you still have a TON of hand written assembly running on your computer

Sure a compiler can't beat hand-scheduled and hand-tuned assembly code. However using C the compiler can then optimize
based on target architecture features like cache size, instructions supported, instruction combinations to avoid.
So while hand-tuned assembly might be faster on one particular cpu, a C compiler can output assembly almost as good
for any supported cpu. Also, C code is more readable than the avx-optimized x264 assembly code.

[log0]

From my understanding this is context switching code. I doubt that there will be any measurable performance impact, as switching is not exactly cheap.

[carewolf]

From my understanding this is context switching code. I doubt that there will be any measurable performance impact, as switching is not exactly cheap.

And the main cost is not execute code, but the fact that caches becomes invalid.

[blubbaer]

Sure a compiler can't beat hand-scheduled and hand-tuned assembly code. However using C the compiler can then optimize
based on target architecture features like cache size, instructions supported, instruction combinations to avoid.
So while hand-tuned assembly might be faster on one particular cpu, a C compiler can output assembly almost as good
for any supported cpu. Also, C code is more readable than the avx-optimized x264 assembly code.

A Compiler can't optimize for cache size or I havent seen one doing this. The programmer is responsible for designing the data structure to be cache friendly.

Compilers could do a better job if they get more hints from the programmer. C keywords like const and restrict are examples for such hints. If you use them properly then the compiler can generate good and fast code.

[gens]

A Compiler can't optimize for cache size or I havent seen one doing this. The programmer is responsible for designing the data structure to be cache friendly.

Compilers could do a better job if they get more hints from the programmer. C keywords like const and restrict are examples for such hints. If you use them properly then the compiler can generate good and fast code.

yes, compilers could do a better job if they gets hints
like alignment hints, inline, static etc
those are language hints and C is low enough to be able to have them

can it help the compiler make a faster function then a human could ?
no, not really
just look at something like glibc's sse2 memcpy, no compiler is able to make anything like that
i made a matrix multiplication function, that a compiler has even less chance of doing then that memcpy

some hints, that i think gcc extensions exists, that no "normal" C programmer would know how to use
and that is C, higher level languages do a lot worse

[Mike Frett]

Good heavens why? If I had my way the entire Kernel would be written in assembly.

[Guest]

This is the problem with assembly code, if it isn't well structured and documented even the original programmer will have trouble understanding it. It is very possible that nobody really knew what was going on with the code.

That is ture of any code and to give a counter example, there are programmers who can read disassembled binaries with minimal extra effort required when compared to reading original code (only problem being properly identifying function parameters).