This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: extended asm


Ankit Jain <ankitjain1580@yahoo.com> writes:

> "The compiler does not interpret the "movb %3,%0" part of this asm
> statement, except to substitute %-escapes when writing out the .s
> file." what is this .s file?  what do u mean by that compiler dont
> interpret the instruction?

When you compile a C program to an executable, the command line 

$ gcc test.c

invokes four programs: the "driver", whose job is simply to hand off
control to the other three; the "compiler", which reads the C program
and translates it to assembly language; the "assembler", which reads
the assembly-language translation and converts it to machine code; and
the "linker", which reformats the machine code into an executable
file.

The "compiler" part has only limited understanding of an asm().  It
understands the constraints, but it passes the assembly language
string directly to the assembler (substituting operands).  It doesn't
know that your assembly language string is only touching two of the
operands.  It believes you when you say both "c" and "d" are given new
values in the asm statement.

Because it believes you, it thinks it's free to do other things with
the registers for "c" and "d" before the asm statement.  For instance,
it sees that "d" is set to 0 and then immediately set again by the
asm, so it throws away the assignment of 0 -- and uses the same hard
register for "d" and "b".

> now my question was when i have moved only one value i.e b->c then d
> is also initialised with some value.

And your answer is, because you claimed to have initialized d with
some value, it stuck something else in the 'd' register before the
asm() statement, and you're seeing that value because you didn't live
up to your claim.

(Tangentially - even if you *had* written two move instructions, it
would not be sufficient to prevent this sort of thing happening; GCC
assumes that an asm statement consumes all its inputs before writing
any of its outputs.  The safest way to avoid this is to write exactly
one asm instruction per asm() statement.  If for some reason you can't
do that, there is a notion of "earlyclobber" - check the manual for
details.)

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]