This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Documentation of x87 extended inline assembly
- To: "Dieter Buerssner" <buers at gmx dot de>,<gcc-bugs at gcc dot gnu dot org>
- Subject: Re: Documentation of x87 extended inline assembly
- From: "Tim Prince" <tprince at computer dot org>
- Date: Tue, 16 May 2000 07:23:06 -0700
- References: <200005160919.FAA10930@sendmail1.computer.org>
Many of these problems have been solved in the glibc-2.1.3 revision of <bits/mathinline.h>. Yes, clobbers are required when
additional entries are made on the cpu stack beyond those designated with = (i.e. "=t"). Evidently, there has been confusion over
this.
----- Original Message -----
From: "Dieter Buerssner" <buers@gmx.de>
To: <gcc-bugs@gcc.gnu.org>
Sent: Tuesday, May 16, 2000 2:23 AM
Subject: Documentation of x87 extended inline assembly
> There seems to be some lack of documentation of x87 inline assembly
> for gcc. One problem is, that I have found no way, to tell gcc, how
> many additional entries in the FPU-stack the inline assembly will
> use. A small example may be
...................
> For a inline version, this could be formulated as
>
> __inline__ long double my_logl(long double x)
> {
> long double y;
> __asm__ volatile(
> "fldln2\n"
> "fxch %%st(1)\n"
> "fyl2x"
> : "=t" (y) : "0" (x));
> return y;
> }
>
> The non inlined version will probably be ok. When inlined, there
> seems to be the possibility, that gcc will already have cached 7
> values on the FPU-stack, and the stack will overflow.
Yes, this is the type of bug which was corrected between glibc-2.1.2 and 2.1.3.
>
> Similar, one might want to write
>
> long doube logbasel(long double x)
> {
> static const long double log2const=...;
> long double y;
> __asm__ volatile("fyl2x", "=t" (y): "u" (log2const), "0" (x)
> : /* what goes here? "u"? */);
> return y;
> }
>
> I have not found documentation, what there should be in the clobber
> list here.
>
__asm__ ("fyl2x", "=t" (y): "u" (log2const), "0" (x) : "st(1)" );
> A similar problem is i.e. with fxtract, that produces one additional
> entry in the FPU-stack. The following seems to work
>
> long double x, y, z;
> __asm__ volatile("fxtract" : "=t" (y), "=u" (z) : "0" (x));
>
> I have not found this feature documented, but it seeems logical.
Yes, where y is discarded.
I don't know why volatile is so often used in these situations. Perhaps it would make buggy asm() work more consistently.
>
> Regards,
> Dieter Buerssner
>