From: eplmst AT lu DOT erisoft DOT se (Martin Stromberg)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Assembler smal question
Date: 7 May 2001 08:17:47 GMT
Organization: Ericsson Erisoft AB, Sweden
Lines: 73
Message-ID: <9d5lnb$j3k$1@antares.lu.erisoft.se>
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> <9d485u$4qi$1 AT node17 DOT cwnet DOT roc DOT gblx DOT net>
NNTP-Posting-Host: lws256.lu.erisoft.se
X-Newsreader: TIN [version 1.2 PL2]
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Alexei A. Frounze (dummy_addressee AT hotmail DOT com) wrote:
: > 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

They are: "mov byte ptr [bx], 1" vs. "mov [ byte ptr bx ], 1". Perhaps
even "mov byte [ ptr bx ], 1" is valid?

BTW, perhaps you'd like to tell me if "mov byte ptr [bx], 1" si the
same as "mov byte [bx], 1"? If not what is the difference?

: 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

That's because they are necessary for the compiler to know what has
changed. It's a feature... And it's a very flexible interface between
your assembly code and C code.

And you only need those weird things if your doing inline assembly in
C. Not if you code in pure assembly. (You do need the size suffixes
though.)

: > 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.

Well I don't have any problems with any CPU that GCC and GAS
supports... (Not really as can't know because I haven't been close to
a lot of those CPU.)

: > 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

Well I thought you were saying that the inline assembly of bcc (or TC
or something) was better than GCC's. If you're not talking about some
compiler what are you comparing GCC with?

: 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.

Not if what bcc is hardcoded to preserve isn't any good for
you. Optimise is the word here.

: >  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.

Why should I save SI or DI if I don't have to? Why should the compiler
need to reload BX if I haven't touched it?


Right,

						MartinS