flat assembler
Message board for the users of flat assembler.

flat assembler > High Level Languages > Why C is so heavy ?

Author
Thread Post new topic Reply to topic
Fulgurance



Joined: 27 Nov 2017
Posts: 42
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:
Code:
void _start(void)
{
 *(volatile char*)0xB8000='A';
 while(1);
}    

With:
Code:
zohran@msi-gs73vr-6rf OS % gcc -fno-pie -m32 -c main.c                               
zohran@msi-gs73vr-6rf OS % ld -m elf_i386 --oformat binary -Ttext 1000 main.o -o main    


And assembly:
Code:
org 0x1000
use32

mov byte [0xB8000],'A'
main:
jmp short main    


Is it impossible to have the same result with C i think ? If i understand very well, use C language is very expensive ...
Post 02 Jun 2018, 10:49
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16047
Location: 112 Ocean Avenue, Amityville
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?
Post 02 Jun 2018, 17:43
View user's profile Send private message Visit poster's website Reply with quote
MSrobots2



Joined: 21 Oct 2017
Posts: 12
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
Post 03 Jun 2018, 16:33
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16047
Location: 112 Ocean Avenue, Amityville
MSrobots2 wrote:
Smaller size does not inherently make code faster, for example. When you 'unroll' a loop sequence it will be longer, but faster.
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.
Post 03 Jun 2018, 16:43
View user's profile Send private message Visit poster's website Reply with quote
MSrobots2



Joined: 21 Oct 2017
Posts: 12
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
Post 03 Jun 2018, 16:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16047
Location: 112 Ocean Avenue, Amityville
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. Sad
Post 03 Jun 2018, 17:09
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 476
Can you decompile the C output? Please post it here.
Post 06 Jun 2018, 14:43
View user's profile Send private message Reply with quote
Walter



Joined: 26 Jan 2013
Posts: 131
Image
Post 06 Jun 2018, 16:01
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.