Thread: Assembly in C code?

Yes and no. If I recall, a compiler will transform C code into ASM code and then put the ASM code into binary form. Don't quote me on that though.

Assembly is the syntax of machine language.

Let's say return is 0x7F. So anywhere in an executable file you have 0x7F, disregarding prior context and any previous opcodes occurring, this would execute a return from a subroutine back to the caller.

But 0x7F could also represent an address, an offset into a segment, a segment, a portion of a descriptor, an immediate value, etc, etc.

Data is simply just numbers. It's how data is interpreted that matters.

A simple linear interpolation in x86 asm using the FPU.

Code:

proc   LinearInterp
ARGS v1:QWORD,v2:QWORD,Interp:QWORD

push  ebp
mov   ebp,esp

fld [v2]
fsub [v1]
fmul [Interp]
fadd [v1]

pop ebp
ret
endp

Inline asm

Code:

float LinearInterp(float v1,float v2,float Interp)
{
  __asm {

   fld [v2]
   fsub [v1]
   fmul [Interp]
   fadd [v1]
   
  }
  return st(0);
}

>Isnt C just a higher level ASM?
No.

>If I recall, a compiler will transform C code into ASM code and
>then put the ASM code into binary form.
Not necessarily, though it's up to the compiler. It's generally easier to translate C into assembly and then assembly into machine code (gcc/as is a good example), but it's more efficient to translate C directly into machine code. Since compilation time is an issue among compiler writers, the most efficient way usually wins.

In a lot of compiler's there's an intermediate code generation phase in which your input (after being lexed, parsed and semantically checked; aka after being processed by the front end) is taken and translated into a 'easily readable, easily compilable' intermediate stage. The basic standard for this language is pretty much that it's easily readible and easy to generate machine code from. The reason a lot of compilers take this option is so that they can then optimize that intermediatary input as needed to still produce the correct ouput but do it in a more 'efficient' manner (although *how* the compiler optimizes it is really up to what you want these days, i.e. size vs. speed.) Also, this allows you to easily swap out the back end of the compiler (the part that generates the machine code) with another so you can port the compiler inbetween architectures. That is, you only have to rewrite a very small portion that is 'modular' rather than grounded to one specific architecture; it would be much easier to take an already existing compiler and swap out the part that generates x86 assembly with SPARC assembly rather than just rewrite the whole compiler to get it to work on a SPARC machine. A lot of people have gone through the trouble of making/researching compilers for several languages, who's front ends all generate the same intermediatary language so that you could for example, write Java code and C++ code and stick them together. This field has only made so much progress however, as there are all sorts of little semantic 'gotchas' that a language can throw at you. .NET is a very good attempt at language interoperability so far though (probably the best), but I will say it isn't perfect and there are things that still need to be done.

in gcc, but it's backwards worthless at&t syntax

There's an intel option you can use that will let you use intel-based syntax in your inline assembly.

Assembly is the syntax of machine language.

Assembly is the delineation of the processor's opcodes that it executes directly. Normally it is very processor specific, but it is also very tool specific which is why there isn't really a standard defined for using assembly on a certain machine. It all depends on what assembler and processor you're writing for.