www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/05/17/06:55:29

Date: Sun, 17 May 1998 13:55:10 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: djgpp AT delorie DOT com
Subject: Re: Inline assembly in djgpp
In-Reply-To: <6jikj4$ohh$1@grissom.powerup.com.au>
Message-ID: <Pine.SUN.3.91.980517135423.14173A-100000@is>
MIME-Version: 1.0

On 15 May 1998, Herman Schoenfeld wrote:

> c) it's extremely non-portable

I think GCC's inline assembly is more portable than Watcom's, or any
other compiler's.  You can't really talk seriously about portability
of assembly code, but at least GCC's inline syntax (I mean the syntax
of the inline statements, not of the assembly code you are inlining)
is the same across all the platforms GCC supports.  So at least you as
the user don't have to re-learn how to use inline code when you move
to another platform.

> d) it would be easier to add intel asm support

This is a totally different issue.  The assembly syntax (Intel vs
AT&T) is orthogonal to the way you ``explain'' to the compiler what it
needs to know about the side-effects of the inlined code.

> oh - it can optimise 
> inline assembly. That's just great. If i wanted the compiler to do that 
> then i'd just write in plain C code.

No, GCC doesn't optimize inline assembly, it emits it verbatim.  What
it does is to let you use assembly without disrupting compiler's
optimizations of the *rest* of the code.  The rich set of the
so-called ``constraints'' lets you specify to the compiler what are
the side-effects of your inline code, so that the optimizer doesn't
have to forget everything and restart after the inline fragment.

- Raw text -


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