AltiVec in the kernel

Segher Boessenkool segher at kernel.crashing.org
Sat Jul 22 13:09:57 EST 2006


> Freevec was being developed as a "perfect opportunity". glibc-ports
> came to life and was something that code could be contributed to.
> Since it was such a hassle dealing with the glibc guys, it ended up
> being a seperate library for now.

Do you have a pointer to an archive of that email thread?  I can't
remember it.

You could give Freevec a whole lot more exposure, to people who
might be more interested in it than the average glibc user, by
putting it into uClibc first.  Additional advantage is that you
don't have to care about forward/backward compatibility issues,
or even whether the platform a binary ends up running on actually
has AltiVec or not (uClibc gets tailored to the exact system it
runs on at compile time).  So you can focus on the routines you
want to speed up instead of on all the infrastructure stuff
required for glibc.

You'll have to update uClibc's PowerPC port first though (mostly
just copying stuff from recent glibc) -- it seems the libc AltiVec
support (for handling setjmp() etc.) isn't in there yet.

>> This task could be as hard as writing the code in the first place.

Not as hard.  Way, way harder instead.  Part of that is that the
code probably really isn't good enough yet, sorry.  And then there's
all the compatibility stuff, and symbol versioning, etc.  And the
communication issue, of course.


Segher




More information about the Linuxppc-dev mailing list