Mail Archives: djgpp/2001/05/06/15:30:05
"Martin Str|mberg" <ams AT father DOT ludd DOT luth DOT se> wrote in message
news:9d32ak$e77$1 AT news DOT luth DOT se...
> Alexei A. Frounze <dummy_addressee AT hotmail DOT com> wrote:
> : Second thing is that GCC doesn't support native for x86 CPU assembly
> : language syntax but instead it supports AT&T syntax wich is more
complicated
> : and I guess it's still in use in GNU software due to compatibility
reasons
> : and is not very good to write assembly stuff in it.
>
> I object to that statement. AT&T syntax is not more complicated. It's
> actually more consistent than what Intel came up with. E. g. it has
> it's "mov" operands in the right order. If Intel wanted a load
> mnemonic they should have used "ld" not "mov".
I don't have anything against instruction name, it could be anything even
"copy". It's not the point....
> And to use suffixes on
> the mnenonics to show what size the operand is is a lot better than
> sprinkling "byte", "word" or "byte ptr" randomly among the operands.
They *aren't* randomly spread. They do exactly the same thing as in AT&T
characters "b", "w" and "l" being added to instruction name would do, they
specify size of data. But they don't have to be written everywhere, there
are places where it's obvious what the operand size is. ut the thing is that
with AT&T you need to have those b/w/l everytime, even when obvious "mov ax,
1" is considered, it would be "movw $1, %ax". In something like "mov byte
ptr [bx], 1" we can't avoid "byte ptr" thing and either way we have to
specify size of that "1". But there is yet another thing to think about. In
MASM and TASM, assembler knows sizes of variables declared by DB/DW/DD/etc
and you would not need to write anything but "mov [my_variable], 1" or even
"mov my_variable, 1" or "mov my_variable, ax" or "mov [bx], ax". Does AT&T
have this kind of thing or we still need to write those weird $ and % signs,
specify operand size and put there parentheses? I guess it doesn't. Now tell
me who is going to write these extras each time and make the source hard to
read? Only those, who either learned AT&T as a first thing and get used to
it so that they don't change anything, it would require to learn more. But
normally, somebody who is new to assembly language and in particular to x86
ASM, would hardly choose AT&T. Besides, there are too many examples, books
and other documentation easily available on x86 ASM with examples for MASM,
TASM, NASM in intel syntax, etc, so why complicate the life? WHY???
> Now I can understand why someone brough up with TASM or MASM think
> it's more difficult than what your used to, but if you without
> prejudice try to go the other way you'll find that AT&T syntax is lot
> better.
As a matter of fact, I did make some stuff in AT&T syntax, I'm *not* talking
about something I've never tried. And I don't want those weired extras in my
programs.
> So it depends on what you're used to.
^^^ as I mentioned above, only if for some reason that was a first thing to
learn and it could not be intel but necessary AT&T. If when I started
learning assembly language, I was offered to choose between intel and AT&T,
I would choose intel.
> Now for some really good points in favout of AT&T:
>
> If you learn gcc's assembler syntax, you'll have no problems writing
> code for another processor architecture than x86.
I don't have problems with z80 and i8051, note that they are not x86 :)
Well, I know AT&T, perhaps not as well as I want and it makes me thinking
how to do something in it instead of just doing, but that certainly is not a
problem for me. It will come handy if I need to do something in it.
> gcc's inline assember syntax is miles ahead of what you can do with
> bcc.
I didn't mention bcc, though, I meand gcc and assembler :) But I guess a
stand alone assembler is miles away from inline ASM as well, and with intel
syntax several miles away from as/gas :))
> You can tell the compiler exactly what register it clobbers
> e. g.. m not good at bcc
Yes, this is nice and may be useful for the optimizer, though if you know
what bcc expects to be preserved, you will do fine too.
> perhaps this possibility exists there as
> well, but if so they hid the documentation saying how to do that
> pretty well.
As far as I remember, tcc and bcc (at least old ones, for DOS) needed to
save SI and DI. Haven't checked that for bcc5.
Good Luck
--
Alexei A. Frounze
alexfru [AT] chat [DOT] ru
http://alexfru.chat.ru
http://members.xoom.com/alexfru/
http://welcome.to/pmode/
- Raw text -