This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] llrintf, etc. x87 implementations


Hi Dave,

Dave Korn wrote:
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.


The current functions in libm/machine/i386 are the fast-math versions which is why they are predicated with f_. You shouldn't do that when adding new math routines.


  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?


Yes. Overriding works on the .o (.lo) name. If you supply an alternate file with the same name in a machine or sys directory, it will get copied on top of the shared version before the library gets put together and this in turn overrides the previous version. Care has to be taken to make sure you supply all the interfaces for the file you are overriding (e.g. some files contain both an _r and non-reentrant version and you must supply both in your override version).


  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.


1) isn't a problem. Your library contents will be added to the libm library. Any new functions you supply will be added just fine. I would suggest sticking to the same name style as libm/common libm/math to handle the case where a shared version is later added or you might do it yourself.


2) is more difficult. If you have written them in assembler and SOFT_FLOAT is defined to indicate there isn't native floating-point support, then either you need to supply an alternate written in C (which might as well go into the shared math library) or create stubs that always return failure or document they simply don't exist in such a case. Soft float doesn't prevent C code using floating point from working, it just means there is a whole lot of work being done by the compiler behind the covers and subsequently isn't that fast.

  [  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.  ]


Discussed above. They are fast-math versions, designed for applications that are feeding them reasonable values (i.e. they don't screen for domain and range errors (e.g. log(-1)). They take advantage of any hardware instructions. Not the same situation here.


Hope this helps.

-- Jeff J.

  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


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