Well it might be a very basic question but I am still confused .

Whenever we write an architecture specific code we write it in assembly language(which gets converted into machine lang by assemblers).

But when we write a normal c code our compiler changes it into assembly code which is again architecture specific.And for different architectures we have different compilers changing into architecture specific code .So then what is the necessasity of writing in assembly language.Why cant all the code written in c language and let the compilers change them into assembly language.As for arm architecture there are arm gcc toolchain converting c code into assembly specific to arm architecture.

Please correct me if I am wrong as I am new to these topics.


Thanks in advance

While todays compilers are pretty clever there's always hope that
some humans do better at optimising the way an algorithm may be
written/implemented in assembly/machine code. I will hazard the guess
(hope?) that there may be some such smart people in your company.


Cheers,
Tink


P.S.: Moved to programming for better exposure.

Well, one legitimate reason to do this is if the assembly code is so low-level that it would be impossible to express in C.

This is probably the only good reason to use assembler code these days. Trying to out-optimize a modern C compiler is very difficult.
I don't think it is still the case that assembler code is generated as an intermediate step in modern compilers (gcc). It is still possible to generate assembler output (gcc's '-S' option), but it isn't normally generated.
--- rod.

Some operations are too architecture specific to represent in C.

That covers operations you can represent in C that only become architecture specific as a result of translation to asm. It doesn't cover operations that are inherently architecture specific.

How do you request service from the OS? As a C programmer, you call some library function to request the OS service for you. But how does the C code inside that library function finally request the service? C can only call functions. In most OS's the actual request for service is something architecture specific that is not a function call.

How does that OS routine return control to your process when the requested service is done? That is also architecture specific beyond what can be represented in C.

Many other things a kernel and/or device drivers might need to do have no representation in C.

Typically those are all done in inline assembler within C source code. But that is still human written asm code, not asm code created by translation from C.

Yes it is difficult.

Within what can be represented in C, there are still rare cases where the compiler doesn't translate well enough. When you need to squeeze a little more performance out of the most performance critical loops, sometimes a human can do better.

Sometimes a project demands you do something difficult.

1 members found this post helpful.

It is actually true that the earliest "C" compilers generated assembly source-code that was actually assembled by a separate program. And, such "separate programs" do still exist. Some parts of Linux, such as the "trampoline" code that's used during the earliest stages of the boot process, are pure-assembly source code.

But, most of the time, assembly constructs are embedded within "C" programs using e.g. the asm { } directive. Assembly-level statements can be included within a subroutine, or the entire subroutine can be written in assembly-level statements, and the whole thing is processed directly by your friendly nighborhood "C" compiler.

So, when would you actually use this? The short answer is, "almost never." The proper answer is, "when you need to specify an actual sequence of processor-specific machine instructions."

The genius of the original Unix system, and the impetus for writing "C" in the first place (literally as "a language to write Unix in..."), was the recognition that nearly all of the code in a production operating system isn't machine-specific at all, and doesn't need to be written in assembly. (The much-maligned MULTICS system was a fat gob of assembler.)

As time has gone by, microprocessor designers now engineer their instruction-sets, not to be generated by people writing assembler code, but by language compilers. They teach language-compiler designers how to generate highly-optimized instruction sequences for this-or-that microprocessor model, and they often supply compilers of their own which can wring absolutely the most horsepower out of the chip. (They use those compilers to create benchmark programs so that their chips score as high as possible.)

1 members found this post helpful.

I assume you never looked at any of the MULTICS source code.

In fact it was a fat gob of PL/I with very little asm.

CTSS, was coded in assembler. It was used with a higher level language named BCPL (one of several unrelated early languages with that name). But the OS itself was not coded in BCPL.

ITS was based on CTSS and was coded in a mixture of assembler and B (slightly more assembler than B). B was invented for the purpose of writing ITS.

MULTICS copied a lot from ITS, but added massive design bloat and switched to a much less efficient higher level language.

UNIX derived its name from MULTICS, but since MULTICS was a much longer project started before UNIX but not working until after UNIX, most of the design ideas for UNIX came directly from ITS, not through MULTICS.

C got its name and most of its concepts from B.

Very good questions. The answer is: don't write Assembly code if you can avoid it. Really: you have to have a very specific reason to use Assembly.

A trivial example would be the /arch directory of the Linux Kernel, where arch-specific assembler routines are. You'll find code there for the low level parts of memory management and interrupts, among other stuff.

Assembly is pretty much required for performance-critical applications like video encoding and cryptography. Compilers can't take full advantage of advanced features in the processor (SSE2 and such). There's a lot of performance "cheats" available to hand-written assembly that the compiler can't take advantage because you as the programmer knows a bigger picture than the compiler. On a register-starved architecture like x86, merely doing better register allocation so you don't have to touch memory unless you absolutely have to produces ridiculously huge wins (many times over 50%). On a saner architecture like PPC, there's pretty much no special tricks you can pull that the compiler doesn't know about already.

Oh, and compiler intrinsics and the asm directive can get very messy very quickly. They're great when you only need a few special instructions, but not really feasible for anything at all complicated.