RE: [RFA] llrintf, etc. x87 implementations

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

On 06 November 2007 18:35, Jeff Johnston wrote:

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

  Yeh, I've been reading through that Sun stuff.  Gnarly!  I could try and
make an llrint implementation from the existing lrint by dumbly changing all
int-sized variables and calculations to long long int and making sure
everything gets cast very early so that I'm getting all the intermediate
calculations done with enough precision all the way through, and I think that
ought to work, but I'd have to be a bit happier with the intricacies of
rounding FP in the binary representation before I could tackle adding a soft
version of rintl.

  So, should I try and detect the SOFT_FLOAT case in the makefile, and not add
my files to LIB_SOURCES in that case, or would it be acceptable to take the
easy way out and when SOFT_FLOAT is in effect, just #if out the whole contents
of the files and instead #include the corresponding .c file from libm/common
by a relative path directly in my machine/i386 .c file?  

  (I know that sounds gross, but it's not like it isn't reliable enough - the
question is whether it might break or confuse something like dependency
generation.  I'm very much hoping you'll say it's ok, because I'd be worried
about trying to infer the SOFT_FLOAT status from makefile string-processing
tests on CFLAGS when there could be all sorts of environment or target-related
factors confusing the issue, but I could probably use a dummy compile with -dM
and grep to find out whether or not the preprocessor thinks it's defined or
not if it was necessary).

  I've also been looking at how to add documentation.  As far as I can tell,
"make doc" doesn't recurse down into the machine-dependent directory, and
although there's a thing called 'targetdep.tex' in
${builddir}/${target}/newlib/libm, I don't /think/ the files in the machine
dir get CHEWed at all and so can't be contributing to it, yes?  I figured out
how to transplant the various doc-related rules into the i386/Makefile.am, and
changing right down into the build dir and running "make doc" there gets as
far as building the .def files and cat'ing them together, but I'm not sure how
I could get this fragment included seamlessly into the main output doc.  (The
right answer in fact probably doesn't involve cat'ing them all together, like
the libc and libm makefiles do, because then they'd have to go in the docs in
a single chunk rather than inserting new functions in alphabetical order
amongst the other @page/@include directives).

> Hope this helps.

  It certainly did, thank you!

  BTW, one more nomenclature thing: I see we have s_XXX for functions working
with doubles and sf_XXX for functions working on floats, but I couldn't find
anything that would tell me what prefix to use for the long double versions
rintl, lrintl and llrintl.  I arbitrarily picked on 'd' because that makes 's'
and 'd' look like they're referring to single and double something, but I
wondered whether I'd missed a convention that I should have used?

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