Message-ID:	<39084DC4.4F8EFB@mtu-net.ru>
Date:	Thu, 27 Apr 2000 18:25:08 +0400
From:	"Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
X-Mailer:	Mozilla 4.72 [en] (Win95; I)
X-Accept-Language:	en,ru
MIME-Version:	1.0
To:	Dieter Buerssner <buers AT gmx DOT de>
Cc:	djgpp AT delorie DOT com
Subject:	Re: THE CONCLUSION
References:	<20000427104804 DOT 5E0F1785B5 AT mtu DOT ru>
X-Recipient:	buers AT gmx DOT de
Reply-To:	djgpp AT delorie DOT com

Dieter Buerssner wrote:
> 
> On 26 Apr 00, at 15:25, Alexei A. Frounze wrote:
> 
> > To make things a bit clear... I've always used the "g" thing for passing
> > parameters to inline assembly blocks. Now AFAIK it's wrong. "g" may be used for
> > eax, ebx, ecx, edx or variable in memory.
> 
> Or esi, ebx, ebp, or an imediate constant.

According to Brennan Underwood's Guide to Inline Assembly available at the DJGPP
web-site:
----------------------8<----------------------------
g        eax, ebx, ecx, edx or variable in memory
----------------------8<----------------------------
Is this manual faulty as well?

BTW!!! There is the same doc (slightly modified) that I refered to write my
inline assembly. It's a  DJGPP QuickAsm Programming Guide by avly. And it's
available at DJGPP site as well. 

So, I strongly recommend to delete it from the site, since everyone who use it
can have my problems with inline asm. If there was no such a tutorial I would
come up to the NG with something different than my inline asm troubles.

> > Then some of people appearing in the NG said me that my inline assembly code
> > makes all the problems and that is not a bug in the compiler. I still doubt that
> > GCC has a good behaviour here. It must either compile normally my inline
> > assembly w/o depending on the optimization switches or fail with the same error
> > messages again w/o regard of those switches.
> 
> This is IHMO a valid point. It would be nice, if GCC could
> "understand" inline assembly. Then it could warn you. Like it is, GCC
> doesn't really try to understand the assembly code, it just treats it
> in a formal way. I can't imagine that this will change soon/ever.

Yup. Very silly desging, though. I don't like unpredictable software.

> > What we have now:
> > - fixed inline assembly
> > - yet another pretty efficient optimizing compiler :)
> > - faster 3d engine
> > - some real experience we all can learn from
> 
> - hopefully the insight, that inline assembly is not that easy and
> needs the careful reading of the documentation.

Sure thing. At least GCC's inline asm with AT&T syntax seems overwhelming.

> - don't use inline assembly for everything

:)

> - your wise conclusion ;)

:)

Thanks Dieter.

Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror:   http://members.xoom.com/alexfru

- Raw text -