This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Documentation of x87 extended inline assembly


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]