[RFA] llrintf, etc. x87 implementations

["Dave Korn" <dave dot korn at artimi dot com>]

    Hi Jeff, et al.


  As we discovered a little while ago, in a thread starting at

http://cygwin.com/ml/cygwin/2007-09/msg00590.html

newlib's lack of an llrintf implementation is a hindrance to building various
packages (MPlayer and FFmpeg prominently among them) on the Cygwin platform.

  To that end, I'd like to contribute implementations of that and the related
family of functions.  For the purposes we need them for on Cygwin (e.g.
codecs, streaming), it doesn't make sense to use anything but the x87 fpu
instructions.

  So, I've been adding files to libm/machine/i386, but I've been doing it with
a fair amount of guesswork, cargo-cult coding and cut'n'pasteology.  My
approach works, but I think it's not right, and could use some advice on a
couple of points about the newlib naming scheme and how to use overrides.

[ref. Work-in-progress patch attached - not a formal submission.]

  For naming them, I just imitated the existing i386-specific files, which are
all named f_XXXXX.[cS].  They also wrap their contents in #ifndef SOFT_FLOAT,
so I did the same.  OTOH, although the existing files didn't test if __GNUC__,
I thought I may as well wrap the highly gcc-specific asms in a test for that
too.

  This builds and creates a library with the right code in it, but when I
looked through it with objdump I found it also still included the original
soft float rint/rintf/lrint/lrintf code.  Fortunately they are ordered with
the machine-dependent ones first, so they override at linktime the soft-float
implementations, but I'm not confident that's the right way to go about it!

  So, my first guess is that I'd have to match the existing filenames:

libm/common/sf_lrint.c
libm/common/sf_rint.c
libm/common/s_lrint.c
libm/common/s_rint.c

to get the machine-specific versions to override the common ones, yes?

  If so, that leaves me two further questions: 1) how can I provide the new
functions (llrint, llrintf, llrintl, lrintl, rintl) when there isn't a common
implementation for me to override, and 2) how do I make this work when
SOFT_FLOAT is defined, since with the #ifndef guards I currently wrap the file
bodys in, that seems it might leave the override taking place and replacing
the existing soft-float implementation with just nothing at all.

  [  I notice that the other f_XXXXX files don't have this problem, because
they're defining _f_XXXX prefixed versions of the math functions they
implement, and so there's probably a header around somewhere that #defines the
standard c library names in terms of the _f_XXXX versions when fast math is in
effect.  But I'm not sure that's the right thing to do when want I want for
most of these functions isn't even switchable versions but just to provide an
implementation sometimes (!SOFT_FLOAT) but not always.  ]

  Have you got any advice you can give me about which is the best way/place to
a) implement the overrides of the existing functions and b) add the new
missing functions in machine-dependent-only versions?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Attachment: llrint-patch.diff
Description: Binary data