Message-Id: <200004270947.FAA27596@delorie.com> From: "Dieter Buerssner" To: "Alexei A. Frounze" Date: Thu, 27 Apr 2000 12:52:02 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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 Precedence: bulk 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 ;)