Known by all is that Assembler language is the fastest for some issues and for this reason it is the most used in the kernel of the different operating systems and the same occurs for real-time projects where advanced electronics are used. The problem comes later, when that code needs to be maintained and it is not, and therefore In the case of the Linux kernel, the developers have chosen to translate that Assembler code to C.
C is the most representative Linux programming language (actually, of all * nix platforms), it was developed by Dennis Ritchie and Ken Thompson in 1972, it was made on a Unix PDP-11 system and was part of Unix version 2. Given its high performance and portability, it began to be used more and more in the implementation of operating systems and therefore Linus Torvalds He used it for his project when back in 1990 he was looking for a free and open alternative to Minix.
Of course, despite so many strengths, Assembler has some advantages over C as we mentioned at the beginning, so this decision has surprised but according to what comments Andy Lutomirsky on the kernel mailing lists your work is well under way and Linux kernel 4.1 will be the first to incorporate this Assembler source code rewrite to C. Specifically, everything related to exits to user mode, which currently consists of a mixture of code from these two programming languages but which, given its low maintenance, is increasingly complicated when updating.
Is that the code in Assembler It has not been updated for a long time and that means that new developers are not completely clear about its operation, and what is worse, it would not be easy to update it. Thus, instead of trying some partial change they have chosen to start changing all those Assembler routines to C, and personally I think that although some execution speed may be lost (which may be minimal if the code C new is efficient) new and clear code is always preferable to having it outdated and with almost zero possibilities of updating because it is not well understood how it was implemented.
In the first place it is ENSAMBLADOR, in Spanish.
Second, all language must be COMPILED (or interpreted), so the goodness of the result depends on the COMPILER (or the interpreter)
As the C compiler has improved a lot and the assembler one very little (because it was already very good), nowadays the difference of a compiled program written in C compared to the same one written in assembler is negligible or non-existent (it wasn't before) .
Even the difference between compiled (C and others) and interpreted (Java and others) programs has also been greatly minimized.
So being much easier to maintain C than assembler, it is a very sound decision to make these changes in the kernel, when doing a cost benefit analysis, weaknesses, threats, strengths and opportunities or any other that works.
for decision making.
To Miguel Mayol Tur: First of all, every programmer who claims to be one speaks ASSEMBLER and understands English. The others use Visual Basic and call themselves programmers. What a shame. And secondly the Assembler DOES NOT COMPILE. What the programs that handle it do is convert mnemonics to bytes directly. Programming in Assembler is speaking to the machine in the same language, but to make it a bit easier, mnemonics are used instead of directly writing the corresponding bytes. There is a one-to-one correspondence between a set of bytes and an instruction in Assembler. But this, of course, only a real programmer knows, one of those who say ASSEMBLER. Consequently, there are no improvements to the "converter" from assembler to opcodes because the programmer is the one in charge of making that improvement. C compilers (and other languages) translate instructions into pre-established macro representations of assembler (or machine code) and the improvements are given by how those conversions are.
Why use C? Because it is easier to review and maintain something that is more readable. Most people don't directly understand assembler opcodes or mnemonics. Simple as that.
Not even I will bother to talk about Java, which although it was imposed as a standard a long time ago is now detested by those who do understand code.
But don't believe me, ask Google if what I said here is false.
regards
Hello Chigüire, my eyes fall from my face thinking that you are not able to write in Spanish without using terms of Anglo-Saxon origin: it is said «assembler».
Of course, in one thing I agree with you, better not talk about java because to say nonsense better leave it. I had a friend who was like you but a carpenter (not an expert programmer) and he said that the best thing was the handsaw and the other tools, not to mention, he even tightened the screws with it. What an example to follow!
The English language is always at the root of all computational terms. That's the way it is, even if we Spanish speakers don't want it. Add to this that there are terms that cannot be translated as "bit", "byte", "unix", "linux", "DOS" and many others. And there are some that COULD be translated but there is no such thing as "CMOS", "CSS", "RAM" because there are some initials that have nothing to do with technology and to top it off they don't even exist in Google. There is no point in translating when the message produced is unreadable. Conclusion: It is preferable for technical or computational issues to use technical terms in English. For the same reason: I prefer to write that I use "windows" to say that I use the operating system "windows". And I prefer to talk about CSS and that I use type = »text / css than to try to say that I use« style sheet sheets with type equal to diagonal text style sheets ». Health.
Programs written in an assembly language are always compiled, never interpreted. However, there is nothing wrong with using Spanish instead of Spanglish. Proper names are never translated, but technical terms are when they are not popular acronyms. Anyway, everyone can speak as they please while we can still understand.