Hello, i have question. Many people say it's better to code with C than assembly for kernel, but when i compare similary code C versus assembly similary code, i have a difference of 71 bytes ! It's heavy !

C:

With:


And assembly:


Is it impossible to have the same result with C i think ? If i understand very well, use C language is very expensive ...

I don't think that C is better for kernel code. I also don't think that assembly is better for kernel code. Each has its own strengths and weaknesses. Often the choice comes down to what the programmer is most familiar with. Sometimes the choice is forced by the platform environment. Sometimes the choice is biased in a particular direction by some other external factors.

But whichever you choose make sure you choose it for the right reasons that suit you. Just because someone else tells you that C is better for them and their project, doesn't mean it will be for you or your project.

If you are concerned about size then usually assembly will meet that goal easily ahead of any HLL. But maybe you have other goals you need to meet, like portability? Maybe you need to pass the project on to someone else to maintain and they only know C? Maybe your boss has decided the choice for you?

Usually HLL compiles down to assembler, but it is debatable if compiler do a good job at it.

There is one group of people claiming that a optimizing compiler can produce 'better' code as a human, other people claim exactly the opposite.

The question here is what is 'better' code?

Smaller size does not inherently make code faster, for example. When you 'unroll' a loop sequence it will be longer, but faster.

As revolution stated portability is a issue, one can get a C compiler for almost every chip out there, yet assembler is not really portable.

Now throw Operating Systems in the mix and soon portability evolves into a nightmare, you need to call system functions for input and output, different on each OS.

Thus people came up with the idea of a portability layer, written for each OS providing a consistent environment on different architectures.

Freshlib is one usable by FASM to run on windows and Linux, as example.

.Net and Java are examples for a even further abstraction, generating bytecodes instead of assembly, there the programmer - if very brave - can write the bytecodes by himself or let his compiler do the job.

Those bytecodes are a intermediate form of a generalized assembler language and on the OS side you have a interpreter or just in time compiler running your instructions and providing the system functions.

Byte code programs are usually very small compared to the same program compiled to assembler, but need a huge chunk of code to be installed on the target system.

And that is the real dilemma here, sadly it does not really matter what language you use to write your program, most of the time 'your' program executes code not written by yourself.

Enjoy

Mike

Of course faster is not always the goal. But if it is the primary goal then we need to be careful about how much unrolling we do. Too much can be just as bad as not enough.

nitpicking, but as usual you are absolutely right about that. I forgot to mention that this also can be different between different models of different chips of different manufacturers and different OSes, even between two identical computer, one set up by me and one set up by you.

But generally speaking....

And just to mention it, my still favorite language COBOL was the first successful attempt to write portable software.

And millions of lines of code moved since 1960 from hardware to hardware, still outperforming any other solution.


Mike

Sometimes I think that JS is taking over the world. I suspect that more CPU time is spent interpreting and running JS code from websites than all other tasks in all other languages put together.

Can you decompile the C output? Please post it here.