delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/27/06:37:09

Message-Id: <200004270947.FAA27596@delorie.com>
From: "Dieter Buerssner" <buers AT gmx DOT de>
To: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
Date: Thu, 27 Apr 2000 12:52:02 +0200
MIME-Version: 1.0
Subject: Re: THE CONCLUSION
CC: djgpp AT delorie DOT com
In-reply-to: <3906D238.888D65F7@mtu-net.ru>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

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.

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

> 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.
- don't use inline assembly for everything
- your wise conclusion ;)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019