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

[lunarcloud]

Removing architecture-specific assembly also means you can share more functionality between architectures and letting the compiler do the optimizations, which is great.

[computerquip]

"Clear" in this context means something like "obvious", as in, when someone wants to make a modification, it takes unreasonable amounts of work to understand the meaning of the code.

If were being real, most real real world code doesnt even come close to the quality of whats in most of the Linux kernel.

[uid313]

I wonder if there is any security vulnerability, backdoor or anything hidden in that messy assembly code that nobody really understands.

[quaz0r]

A compiler is a program that takes in source code and outputs another language. This is typically object (machine) code, but not always: Oracle's java compiler (javac) takes in Java code and outputs java bytecode while emscripten takes in LLVM bytecode and outputs Javascript. An assembler is a special type of compiler which compiles source code written in a machine's specific assembly language in to object (machine) code.

Many older compilers did use to output assembly language source code that would get fed to an assembler, but nearly all native compilers nowadays generate object code directly.

... no.

[-MacNuke-]

Removing architecture-specific assembly also means you can share more functionality between architectures and letting the compiler do the optimizations, which is great.

As long as Linux does not abstract all ISA-specific things with a virtual ISA, this code will be still x86 specific. At this level you have to use special instructions from the CPU (which are different for each architecture) and you have to do different things. The only difference is that they put common operations in C-functions but they are using x86 registers all over the place... only in a different way.

[bpetty]

It is kind of funny that many still think that ASM code means faster code. I can't remember the project... maybe zlib. Some popular library like that found that their ASM version was actually significantly slower than their C implementation after a while. It wasn't that the C code was better maintained, it was that the compiler kept advancing... taking advantage of more and more optimizations. With assembly you have to proactively adjust your code continually because it is not portable and newer optimizations become available that you will miss out on.

[user82]

It is kind of funny that many still think that ASM code means faster code. I can't remember the project... maybe zlib. Some popular library like that found that their ASM version was actually significantly slower than their C implementation after a while. It wasn't that the C code was better maintained, it was that the compiler kept advancing... taking advantage of more and more optimizations. With assembly you have to proactively adjust your code continually because it is not portable and newer optimizations become available that you will miss out on.

That might be true.
Maybe there was a very early version of gcc and someone found out the asm code is much faster, but today gcc can actually produce better results than the old asm.
I expenct Michaels gigantic test farm to find at least one benchmark that shows the results

[Guest]

It is kind of funny that many still think that ASM code means faster code. I can't remember the project... maybe zlib. Some popular library like that found that their ASM version was actually significantly slower than their C implementation after a while. It wasn't that the C code was better maintained, it was that the compiler kept advancing... taking advantage of more and more optimizations. With assembly you have to proactively adjust your code continually because it is not portable and newer optimizations become available that you will miss out on.

Last part of your comment is only true for performance critical parts of the code (e.g. like copy_generic_user_()), code in question is however using asm instructions that haven't changed since late 90's or even from 386 era. So basically, your comment is more valid in userspace assembly programming, but completely off in kernel context (apart from few critical sections like I mentioned).

[gens]

and people that think assembly is hard are full of shit again

this was complicated code because it was a combination of C and gcc inline assembly
gcc inline is ugly in itself

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

if you really think a compiler can do a better job then compile glibc without assembly optimizations
then lets see how your computer really performs with only compiler generated code
(and don't use pixman, x264 and a ton more libraries, games, frameworks etc)

oh ye, and gpu drivers, also compile mesa without asm optimizations

[wizard69]

Isn''t this going to affect performance in a bad way since the compiler might translate C code into machine code worse than from Assembly?

You can't really say for sure until the compiler generates the code. However from this article they indicate complete replacement of a portion of code, This can offer up huge advantages long term and has the potential for slimmer more focused code.

In any event one thing I've noticed about the Linux kernel is the total lack of good commenting in the code. Writing assembly, even C code without comments is almost certain to result in exactly what was described here. That is a bunch of dense code that is impossible to completely decipher or determine original intent. We can only hope this new C code is properly commented.