From: "Alexei A. Frounze" Newsgroups: comp.os.msdos.djgpp Subject: Re: Assembler smal question Date: Sun, 6 May 2001 15:22:02 -0400 Organization: Global Crossing Telecommunications Lines: 99 Sender: UNKNOWN AT 64-212-194-138 DOT nas8 DOT roc DOT gblx DOT net Message-ID: <9d485u$4qi$1@node17.cwnet.roc.gblx.net> References: <9chviu$1ps$1 AT info DOT cyf-kr DOT edu DOT pl> <9ci3t3$g6o$1 AT node17 DOT cwnet DOT frontiernet DOT net> <9d32ak$e77$1 AT news DOT luth DOT se> NNTP-Posting-Host: 64-212-194-138.nas8.roc.gblx.net X-Trace: node17.cwnet.roc.gblx.net 989176830 4946 64.212.194.138 (6 May 2001 19:20:30 GMT) X-Complaints-To: abuse AT frontiernet DOT net NNTP-Posting-Date: 6 May 2001 19:20:30 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Martin Str|mberg" wrote in message news:9d32ak$e77$1 AT news DOT luth DOT se... > Alexei A. Frounze 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/