Problem with "mov" in GNU GAS

Hello everybody,

I am writing a simple ASM code with GNU GAS. I am having some problems
with mov command. Please could anybody tell me why 2 lines (*) and
(**) are not equivalent?? (currently my code works as expected with
(**), but not with (*)

(My program is in 16bit mode)

---
var:
.long 0xf1234

.code16gcc
movl var, %ecx                                // (*)
movl $0xf1234, %ecx                      // (**)


Many thanks,
J
Many thanks,

junkoi  <spamtrap@crayne.org> writes:
> Hello everybody,
>
> I am writing a simple ASM code with GNU GAS. I am having some problems
> with mov command. Please could anybody tell me why 2 lines (*) and
> (**) are not equivalent?? (currently my code works as expected with
> (**), but not with (*)
>
> (My program is in 16bit mode)
>
> ---
> var:
>        .long 0xf1234

So var is an address. At that address is reserved space for a
long, which is to be initialised to 0xf1234.

> .code16gcc
> movl var, %ecx                                // (*)

Here ecx now holds the address where the 0xf1234 above is stored.

> movl $0xf1234, %ecx                      // (**)

But here ecx is set to the constant value 0xf1234.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

"junkoi" <spamtrap@crayne.org> wrote in message
news:94d18289-183c-4a52-9770-48fa230d2943@i12g2000prf.googlegroups.com...
> Hello everybody,
>
> I am writing a simple ASM code with GNU GAS. I am having some problems
> with mov command. Please could anybody tell me why 2 lines (*) and
> (**) are not equivalent?? (currently my code works as expected with
> (**), but not with (*)
>
> (My program is in 16bit mode)
>
> ---
> var:
>        .long 0xf1234
>
> .code16gcc
> movl var, %ecx                                // (*)
> movl $0xf1234, %ecx                      // (**)
>

I don't think it's critical, but I'm assuming the var is in a ".data"
section.

Yes, they are functionally equivalent.  "movl var,ecx" will mov the value at
var's address into ecx, i.e., 0xf1234.  If you wanted to mov the address of
var into ecx [like another responder claimed you were doing...], that'd be
"movl $var,ecx".

Are you linking the .o file?  If not, a zero (0) value placeholder for the
memory address will be in the .o code for "movl var, %ecx".  The placeholder
is not filled in with the address of var until linked using "ld".  Then, the
code should be functionally equivalent.  Is this the problem?  Typically, ld
is used like this, after assembled with AS or GCC:

ld --oformat binary --Ttext 0x7C00 -o mybootcode.bin mybootcode.o

Although very unlikely, you might need to adjust the address size or
segment:

addr32 movl var, %ecx
movl %es:var, %ecx

You can use these for mixed code:

.code16gcc
.code16
.code32
.code64
.data
.text
.att_syntax
.intel_syntax
data16  - operand size override
data32  - operand size override
addr16  - address size override
addr32  - address size override

Let us know...


Rod Pemberton

In message <87abkmra5y.fsf@nonospaz.fatphil.org>, Phil Carmody
<thefatphil_demunged@yahoo.co.uk> wrote:

> junkoi  <spamtrap@crayne.org> writes: 
>
> So var is an address. At that address is reserved space for a
> long, which is to be initialised to 0xf1234.
> 
>
> Here ecx now holds the address where the 0xf1234 above is stored.

No that loads 0xf1234 or whatever happens to be at var into %ecx. THe bug
must be elsewhere.