On Tue, 25 Dec 2001, Nadav Har'El wrote:
> On Tue, Dec 25, 2001, Shlomi Fish wrote about "Re: Implementation of log(x) for
>SPARC32":
> > Actually, usually glibc calls the processor's FPU logarithm routine.
>
> Oops, I didn't know the 386DX's FPU had a logarithm function on it... Nice :)
> Do they also have things like sqrt and cbrt?
>
I think they do. Congrats for Intel. Even though from what I understood of
the glibc code the log() is a base 2 logarithm for some reason. (even
though the tailor series is for log(e)).
> > I did not say it is i386 specific. I'm sure it works fine on SPARCs.
> > However, with things like math, there are separate routines for each
> > architecture. And the SPARC's one is too obfuscated, and I cannot
> > understand how I can rip the relevant code.
>
> Maybe SPARC doesn't have a magic-logarithm-blackbox on its CPU or FPU, so
> it must use an actual algorithm to find the log - which is why it looks
> more obfuscated than a simple call-the-fpu code.
>
Probably. Maybe that was what misled me.
> > FYI, I eventually gave up and coded a logarithm function in perl:
> >..
> > Works like a charm with exactly the same accuracy. I'm going to convert it
> > to C, and by this I will have a truly portable log() implementation for
> > the kernel.
>
> Inventing your own wheels again, are you? :)
> Your algorithm works, no doubt. So will nearly any other algorithm you'll
> divise. What I doubt is that you can't do the same thing with half the number
> of floating-point calculations (divisions, additions, comparisons), so
> if you care about performance (maybe you don't, I don't know) you might
> want to look for the *best* known algorithm, not just *an* algorithm. Maybe
> your algorithm is alread the best possible - I don't know; In that case,
> congradulations :)
>
Performance is not that critical. The algorithm seems to be very fast,
even in Perl. One thing I can do is to totally unroll the for($a...) loop,
but I think I'll skip it because with the loop the code can be modified
more easily.
> > IMO, someone should port stuff like a large part of glibc as well as STL,
> > etc to the kernel. That would make the lives of programmers much easier
> > because they won't have to reinvent the wheel times and again.
>
> But it will make the kernel huge...
> And nobody needs logarithms or bessel functions and such stuff in the kernel
> anyway, except perhaps your very specialized module.
>
What I mean was that there could be source code for functions that
implement those routines, which kernel developers may choose to use. If
they do they can statically link them into their own kernel modules, or
they can put them in separate kernel modules, which will be the kernel
equivalent of shared libraries.
> Next thing, you'll be asking to put a Java virtual machine inside the kernel.
> It would have been useful to run syscalltrack expressions ;)
>
Actually, some people are working on a kernel JVM... :-). And naturally,
there's a kernel web-server and a CORBA ORB in the kernel.
Regards,
Shlomi Fish
> --
> Nadav Har'El | Tuesday, Dec 25 2001, 10 Tevet 5762
> [EMAIL PROTECTED] |-----------------------------------------
> Phone: +972-53-245868, ICQ 13349191 |Seen on the back of a dump truck:
> http://nadav.harel.org.il |<---PASSING SIDE . . . . . SUICIDE--->
>
----------------------------------------------------------------------
Shlomi Fish [EMAIL PROTECTED]
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: [EMAIL PROTECTED]
"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
