Author: Robert Hyatt
Date: 14:15:12 12/09/02
Go up one level in this thread
On December 09, 2002 at 16:53:00, Dieter Buerssner wrote:
>On December 09, 2002 at 16:36:38, Matt Taylor wrote:
>
>>How does AT&T syntax resolve the movzx instruction? You can move 8-bits or
>>16-bits -> 32-bit register. I guess they have movzxs and movzxb?
>
>movzxbl, movzxwl, movzxbw for zero extending for 8-bit to 32-bit, 16-bit to
>32-bit and 8-bit to 16-bit. Same for the movsx.
>
>Perhaps the usage of the register(s) (%al, %ax, %eax) overwrites the b/w/l. I
>forgot - it seems to happen with other mnemonics. If one handles it
>consistently, there is no problem.
>
>I also find the % in register names makes it harder to read. And of course, when
>one reads assembler in both ways now and then, it is very confusing that the
>src,dest is changing.
>
>I have an assembler level debugger, which shows gcc-inline-assembly written in
>AT&T syntax in the Intel way, while it shows the source (of course) in the AT&T
>manner ...
>
>Regards,
>Dieter
While we are on this subject, here is a function that I would like to inline.
It is a newer
Lock() function that is really pretty simple, and it works just find as a
function. But when
I add __inline__ it doesn't work consistently, which seems to imply some sort of
interaction
with the GCC instruction stream it is inserted into. But I am not destroying
registers other
than the %0 type temp registers, which are supposed to automatically be flagged
as
"clobbered"... but it is definitely failing. Does anything jump out at you? I
don't have
any problems debugging assembly code, but this is beyond a code issue and into
some sort
of inline glitch that is apparently overwriting a register that GCC is missing,
or I am
missing:
void __inline__ LockX86(volatile int * lock) {
int dummy;
asm __volatile__ (
"1: movl $1, %0" "\n\t"
" xchgl (%1), %0" "\n\t"
" test %0, %0" "\n\t"
" jz 3f" "\n\t"
"2: pause" "\n\t"
" movl (%1), %0" "\n\t"
" test %0, %0" "\n\t"
" jz 2b" "\n\t"
" jmp 1b" "\n\t"
"3:" "\n\t"
: "=&r" (dummy)
: "r" (lock)
: "cc");
}
I tried changing the "r" to "q" to limit the register choices in case esi/edi
won't work
in some of the above, but I don't see anything wrong. If I remove the
__inline__ then it
seems to work just fine. With the inline in, it breaks things in unpredictable
ways...
Anything obvious (or not-so-obvious) that jumps out at you?
No absolute reason it needs to be inlined other than for a tiny speed gain, but
it has
gotten my curiousity up enough that I am fiddling with it just to understand
what is
happening...
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.