Mail Archives: djgpp/2000/04/15/11:24:58
Hans-Bernhard Broeker wrote:
>Exactly. The problem is that with the AT&T assembly syntax used by gas
>and gcc, it may well be impossible to use the "g" constraint for any
>input/output operand.
This is definetly wrong. The "g" constraint is well suited for
much of the inline assembly on x86 platforms. Floating point
opcodes are special in this respect, because the do operate
on memory directly. On other place where one must take care, is
something like
op %0, %1
where usually only one argument can have the "g" constraint, and the
other argument must have the "r", "q" or "i" constraint.
>No. You just write your code, in whatever way you like. Then you let
>GCC do its job, by telling it how you did yours, as correctly as
>possible. I.e. if you decided to use a register for that operand,
>write
>
> fmull (%0)
>
>and tell GCC to use a register, by the "r" constraint. If, OTOH, you
Let me add here that after the "r" there must be a (dblptr), or
(expression that has type of pointer to double). Also, when you
have an output (say fstl (%0)), "memory" must be added to the
clobber list. Otherwise gcc won't know, that you changed anything.
(Alexei, even when it works without the "memory" with current
versions of gcc, it would be still broken.)
>decide you want to address memory directly, you can write
>
> fmull %0
>
>and tell GCC to use direct memory reference ("m" that is, I think).
Yes, this is what "m" is for. This will also produce much better
code in general. Here, there must be an (dblvar) or (expression that
evaluates to type double). No problem so far, because I think all those
expressions will meet the "m" constraint automatically.
But if I change this to
short cw;
cw = something;
__asm__ volatile ("fldcw %0" : : "m" (cw));
I have seen gcc complaining ("inconsistent operand constraints
in an asm"). This was, because gcc decided to put cw in an
register, for the live-time of the variable. This could be
fixed, by making the type of cw volatile short. But this of
course, may produce worse code in general (not in the example).
Quick testing with the current version of gcc, does not show
that problem. It still leaves an uncomfortable feeling, though.
So, does anybody know, whether gcc has changed in this respect?
--
Regards, Dieter
- Raw text -