[RFA] llrintf, etc. x87 implementations

[Jeff Johnston]

Dave Korn wrote:
> 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 can live with the "plan b" method for now.

You'd have to add dependency statements in the Makefile so that if the 
files you are including are changed, then the machine ones will be 
rebuilt.  Someone could be scratching their head why fixing the file in 
common doesn't seem to do anything.  You also have to make sure the 
include path is correct - shouldn't be a problem.

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

Yes, the machine files aren't being chewed at present as none of them 
have doc comments in them and they are meant to stand-in for already 
commented routines.  The same applies to you if you add files to the 
common directory (i.e. comment the common versions).

Otherwise, I would suggest one of two options: 1) use a flag check in 
the current docs to include an optional section.  Look at 
libc/libc.texinfo.  You will see optional checks for stdio64 and iconv 
sections.  2) Create docs in the libm directory (i.e. don't use per-file 
documentation) and spell out when they are enabled (e.g. i386 only).

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

I cannot comment on the current convention because this was in place 
before I took over newlib.  My choice is sl_XXX in keeping with 
floating-point constant suffixes (f = float, none defaults to double, 
and l = long double).

-- Jeff J.