[davem@dm.cobaltmicro.com: A (somewhat) strange Sparc library issue...]

[Richard Henderson <rth@cygnus.com>]

Yall might have some suggestions as well.


r~

----- Forwarded message from "David S. Miller" <davem@dm.cobaltmicro.com> -----

Date: Wed, 26 Aug 1998 10:56:57 -0700
Message-Id: <199808261756.KAA17119@dm.cobaltmicro.com>
From: "David S. Miller" <davem@dm.cobaltmicro.com>
To: egcs@cygnus.com
CC: rth@cygnus.com
Subject: A (somewhat) strange Sparc library issue...


I have an issue which I'd like to solve for the Sparc port, and I'd
like to describe the situation here to try and get some feedback.  I
don't know what the right thing is to do, so I'm hoping maybe someone
can shed their wisdom upon the situation.

The architecture specification for V8 and V9 Sparc cpu's and their
respective ABIs provide for quad (128-bit) floating point operations
and instructions.  However, these specs leave it up to the implementor
as to whether such operations are implemented in hardware or emulated
in software somehow.  In any event, an ABI conforming Sparc system
must provide one of the two for the execution environment.

For those who chose to implement the software emulation solution,
there are defined library routines a system will provide to implement
the software quad floating point operations.

Here's the kick, nearly all (to my knowledge) Sparc cpus have taken
the software quad floating point route.  Also, in my prepubescent
ignorance I made a huge mistake and did not take care of this end of
things a few years ago for sparc-linux's userland.  Instead I say for
this port that long double's are not 128bits, but are instead the same
as a 64-bit double.

The issue presented is that if I "fix this" by making long doubles on
sparc-linux begin to be 128bits, I have an upgrade nightmare if the
software library routines are placed into glibc for example.  Another
route I could take is to require instead a Linux kernel upgrade which
performs emulation of unimplemented opcodes via traps.  In short a
sticky situation.

So the final possible solution I had considered brings my query here.
What about placing it in one of the libgcc libraries that get built
with gcc?  I have not delved much into the details of how such a
mechanism interfaces, and which library is for what, but I do feel
that this is the ideal solution for my problem.  Once the change in
compiler behavior (generating real 128-bit quad float operations) is
introduced, the library infrastructure appears at the same time.

Another win here is that I get to use it for (my yet to be
bootstrapped) 64-bit Linux Sparc userland on UltraSparc.

Any suggestions?

Later,
David S. Miller
davem@dm.cobaltmicro.com

----- End forwarded message -----