Re: [build system] defaults in C, specializations in asm?

Hi all,

On 13.03.2010, at 07:41, Felix von Leitner wrote:

> Thus spake Markus Wichmann ([email protected]):
>> I am currently enhancing dietlibc's poor libm for x86_64 and came across
>> an idea: would it be possible to write default implementations for
>> necessairy functions in C and have the build system look for specialized
>> assembler versions?
> 
> Sorry for being so unresponsive lately, I am very busy with work.
> That is already what happens.
> .S overrides .c.
> See for example lib/memset.c vs i386/memset.S
> 
>> Place that into a file like libm/exp.c and then tell the build system: If
>> there is $(ARCH)/exp.S put that in as dependency for libm, else use
>> libm/exp.c. That way every arch the support for which is still in
>> development would have a complete if slow library. Adding new
>> architectures would become easier a lot, too.
> 
> That was exactly the idea.
> 
>> I have to admit, though, the trigonometric functions might impose a bit of
>> a challenge.
> 
> There is finished implementations of those elsewhere, and a good
> university library probably has books on how to calculate those with a
> Taylor series or so.  I don't know how they do it in glibc.
> 
> I never really use any libm functions, that's why there are none.
> It would be great if someone sat down and did one.  I think there is
> some portable public domain code for a libm from Sun, but it's really
> old and may not work well on current platforms.  No matter what we do,
> it will involve real work that someone has to do, preferably someone who
> has a good test suite, too.
> 
>> Speaking of which: I saw you use the fprem1 trick for i386 for the sine.
>> Asked rationally: What for? fsin fails to operate if the source operand is
>> outside the bounds of -2^63 to 2^63. But in that case even long double
>> yields far too many quantization errors. Even the addition of one is an
>> idempotent operation in that area. Basically, if the input gets so big we
>> could return anything between -1 and 1 as it is simply impossible to know
>> which angle was the original meaning of the input. Using fprem1 does not
>> necessarily make the result closer to the precise result. (Alway returning
>> zero is OK in that case. And it's faster than trying to recover already
>> lost accuracy.)
> 
> I don't really know enough about libm to do a good decision.
> So I'm inclined to leave it as is, unless you can show me a test where
> it actually improves the result or which shows the result does not
> chance but it takes less time.


Since Summer 2006 we inject the uClibC^WOSX^WFreeBSD^WSun libm into dietlibc in T2:

  http://www.t2-project.org/packages/dietlibc.html 

libm.patch.bz2, libm-i386.patch, ...

-- 
  René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
  http://exactcode.com | http://t2-project.org | http://rene.rebe.de