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

Felix von Leitner schrieb:
> 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.

Since e-mail ain't a real time medium, it isn't to be expected of you to
be online 24/7.

> That is already what happens.
> .S overrides .c.
> See for example lib/memset.c vs i386/memset.S
>

Didn't look into it then. So you already did it like I wanted.

>> I have to admit, though, the trigonometric functions might impose a bit
>> of
>> a challenge.
>
> There is finished implementations of those elsewhere,

Yeah, well, I tried the cephes library, but then decided to resort back to
assembler, because this lib showed me what "slowlyness" means.

> and a good
> university library probably has books

Hey, what's Wikipedia for! OK, unless they deleted that article already.

> on how to calculate those with a
> Taylor series or so.

Nah, looked into it: A Taylor series around zero gets problems when it
comes to repeating the sine: A Taylor polynome of 7th grade yields sin(pi)
= -0.037 or so. I also read a try on how to do a sine with SSE using a
biquadratic polynome (man, I hope that's all right, my math english ain't
too good). It's OK, but it's not the real thing.


> I don't know how they do it in glibc.
>

Assembler. That's what the sysdeps directory is for. In their libm
directory (or was it namend "math"?) all the code there is, are stubs
returning ENOSYS at all times.

> I never really use any libm functions, that's why there are none.

Well, I tried to link gcc against dietlibc, but it complained about a
missing log(). That was when I realized, that the libm is indeed a bit
thin.

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

OK, added it to my to-do-list. At the bottom. Warning: That list is long!
Plus some items of greater priority might queue in before that one.

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

Well, I wrote it the way I suggested for AMD64. Do as you please with it.
5 more functions to do, then I'll publish.

That is, if you only want to comply to the C Standard. If you wish to
comply with POSIX.1-2004 I'll have to do the bessel functions, too, for
instance.

> Felix
>

HTH,
Markus
-- 
Progress (n.): Process through which USENET evolved from smart people in
front of dumb terminals to dumb people in front of smart terminals.