Thread (4 messages) flat view 4 messages, 3 authors, 2003-03-08

Re: Runtime Altivec detection

From: Nathan Ingersoll <hidden>
Date: 2003-03-08 18:21:36

On Sat, Mar 08, 2003 at 03:04:40AM -0500, Bill Fink wrote:
There's also a practical consideration.  For example, in the xine case,
the test for Altivec support is done in the xine library package, whereas
the main() program is in a separate package, namely the xine UI, of which
there are actually several available UIs.  Now if there was a getaux
function similar to the getenv function, this would make matters a lot
simpler.

So while the current xine code may be somewhat ugly, it does work and
is pretty easy to implement within a library.
One issue I saw with the xine code, is if it's in a library, you may want
to use sigaction to save the previous handler, since the app may set it's
own signal handler.

While somewhat ugly, it should be relatively OS independant, and it
could also be used in a callback type fashion for testing instruction
availability on a variety of platforms. The code I linked to in my
original post is an example of this. It could be called with
cpu_detect(mmx_test); on x86, cpu_detect(altivec_test); on ppc, or
cpu_detect(vis_test) on sparc, etc.

Thanks for all the ideas folks, looks like I'll have to consider the
different approaches, or use a combination.

--
------------------------------------------------------------------------
| Nathan Ingersoll           \\ Computer Systems & Network Coordinator |
| ningerso@ruralcenter.org    \\ http://www.ruralcenter.org            |
| http://ningerso.atmos.org/   \\ Minnesota Center for Rural Health    |
------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help