From: Nathan Ingersoll <ningerso@ruralcenter•org>
To: linuxppc-dev@lists•linuxppc.org
Subject: Runtime Altivec detection
Date: Fri, 7 Mar 2003 10:47:53 -0600 [thread overview]
Message-ID: <20030307164753.GA5240@ruralcenter.org> (raw)
I've recently been working on some Altivec optimizations for a library,
and was looking for a relatively clean way to perform runtime detection.
I did quite a bit of searching and didn't find any good examples of
someone doing this, other than using the sysctl call on Mac OS X.
I decided to whip up a simple test program based on the assumption that
running Altivec code on a non-Altivec enabled CPU would cause a SIGILL.
Basically, I setjmp a position before an altivec instruction is
performed, and catch the SIGILL, then longjmp back into the main program
>from the signal handler.
This seems to work pretty well, at least in my simplistic test case. Is
anyone aware of some long term problems doing this? some possible side
effects? I've seen other projects catch the SIGILL and exit on it, are
they not attempting to fix up after because they know something I don't?
If this is a reasonable approach, I'm hoping to extend it for generic
feature testing on a variety of processors. I've heard that the process
state is undefined by POSIX after a SIGILL has occurred, does anyone know
of a platform where this could be an issue?
I've posted the code I'm testing at http://ningerso.atmos.org/code/alt.c
If no one points out a serious flaw to the approach, and the idea is useful
feel free to use the code under the BSD+advertising clause license.
Any comments or insights?
Thanks,
Nathan
--
------------------------------------------------------------------------
| 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/
next reply other threads:[~2003-03-07 16:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-07 16:47 Nathan Ingersoll [this message]
2003-03-07 17:24 ` Runtime Altivec detection Dan Malek
2003-03-07 17:35 ` Nathan Ingersoll
2003-03-07 17:37 ` Anton Blanchard
2003-03-07 17:41 ` Benjamin Herrenschmidt
2003-03-07 17:52 ` Nathan Ingersoll
2003-03-07 18:55 ` Magnus Damm
2003-03-07 18:06 ` Benjamin Herrenschmidt
2003-03-07 18:18 ` Hollis Blanchard
2003-03-07 18:54 ` Magnus Damm
2003-03-07 18:08 ` Nathan Ingersoll
2003-03-07 19:44 ` Magnus Damm
2003-03-07 19:23 ` Nathan Ingersoll
-- strict thread matches above, loose matches on Subject: below --
2003-03-08 2:02 Bill Fink
2003-03-08 2:11 ` Hollis Blanchard
2003-03-08 8:04 ` Bill Fink
2003-03-08 18:21 ` Nathan Ingersoll
2003-03-09 4:01 Albert Cahalan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030307164753.GA5240@ruralcenter.org \
--to=ningerso@ruralcenter$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox