RE: different results on using intel syntax and at&t syntax

["Dave Korn" <dave dot korn at artimi dot com>]

nix noob wrote:
> Dave Korn,

[  Hi NN, you sent this reply to me only, but since it's nothing personal and
the information might be useful for anyone else who has the same problem I've
added the binutils list back into the Cc line.  ]
 
> thanks for replying when i posted this i had access
> two as(1) one was version 2.13 (redhat) other was
> 2.14.... (SuseLinux-9.0 i586 last official as it
> seemed no update was avl to that )

> but in the mean time i asked some one with 2.16 to
> test this code
> and it seems 2.16 behaves quiet correctly as would be
> expected
> may be it was fixed some times between 2.14 and 2.16

  That would make sense.  It's often the case that a bug has already been
fixed in the newest version by the time someone gets to 


> here is a listing on those two as version

>    5                        .intel_syntax noprefix
>    6                    .equ foobar, 0x8001
>    7                    .set barfoo, 0x8001
>    8                    quux = 0x8001
>    9 000a 3D018000          cmp eax, 0x8001
>    9      00
>   10 000f 3B050180          cmp eax, foobar
>   10      0000
>   11 0015 3B050180          cmp eax, barfoo
>   11      0000
>   12 001b 3B050180          cmp eax, quux
>   12      0000
>   13 0021 3D018000          cmp eax, 0x8001
>   13      00
>   14                        .end

> see 3b050180 :)

  Aha!  So we have the beginning of our answer now: it seems that any symbol
generated by .equ/.set/= was being treated as a memory offset, rather than a
constant value that could potentially be an immediate operand.

  If you ever run into problems like this again, and you want to use proper
symbols for numeric constants but can't because of some problem it would
trigger, there is another technique often used: add C-style #define statements
to your assembler file instead of .equ, and use the C preprocessor on the
source before it gets assembled by using "gcc -x assembler-with-cpp" to
compile it instead of "as".

> i coulndt find in those binutils changelog diffs  when
> this behaviour was changed

  In case you don't know yet, there are separate ChangeLogs for each of the
main directories in the binutils source.  You should have been checking the
one in the gas subdirectory, not the main (toplevel) changelog nor the one in
the binutils dir.  (Just trying to be clear).

> since it seems fixed in latest version i think i have
> to upgrade
> ill ask for getting it updated
> sorry for the annoyance

  No annoyance caused, no apologies needed - you have come across a genuine
problem with the assembler, and it's fortunately fixed already.  I took a look
through the gas changelog for you, and I couldn't see what change might have
caused it either, but I was only searching for 'i386', and if it was a generic
change that affected the handling of symbols-vs-constants for all targets I
would have overlooked it.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....