From: Bill Fink <billfink@mindspring•com>
To: Hollis Blanchard <hollis@austin•ibm.com>
Cc: linuxppc-dev@lists•linuxppc.org
Subject: Re: Runtime Altivec detection
Date: Sat, 8 Mar 2003 03:04:40 -0500 [thread overview]
Message-ID: <20030308030440.39fcdc90.billfink@mindspring.com> (raw)
In-Reply-To: <200303072011.54069.hollis@austin.ibm.com>
Hi Hollis,
On Fri, 7 Mar 2003, Hollis Blanchard wrote:
> On Friday 07 March 2003 08:02 pm, Bill Fink wrote:
> >
> > Here is the code xine uses to do run time Altivec detection
> > (from xine-utils/cpu_accel.c):
> >
> > #if defined (ARCH_PPC) && defined (ENABLE_ALTIVEC)
> > static sigjmp_buf jmpbuf;
> > static volatile sig_atomic_t canjump = 0;
> >
> > static void sigill_handler (int sig)
> [snip]
>
> Compared to testing the CPU feature bits supplied by the kernel (for a long
> time now; Ben could tell you exactly how long) this method seems *extremely*
> messy. Please see my other posts (and Ben's) in this thread for details.
OK, here's a sample program that uses the auxiliary vector table to
get the user visible CPU features.
--------------------------------------------------------------------------------
#include <stdio.h>
#include <linux/elf.h>
typedef struct {
int a_type;
union {
long a_val;
void *a_ptr;
void (*a_fcn)();
} a_un;
} auxv_t;
main(int argc, char *argv[], char *env[], auxv_t aux_table[])
{
int has_altivec = 0;
while (aux_table[0].a_type != AT_NULL) {
fprintf(stdout, "a_type = %2d", aux_table[0].a_type);
fprintf(stdout, " a_val = 0x%X\n", aux_table[0].a_un.a_val);
if ((aux_table[0].a_type == AT_HWCAP) &&
(aux_table[0].a_un.a_val & PPC_FEATURE_HAS_ALTIVEC))
has_altivec++;
aux_table++;
}
fprintf(stdout, "CPU %s have Altivec\n",
has_altivec ? "does" : "doesn't");
exit(0);
}
--------------------------------------------------------------------------------
And it seems to work. Here's a run on my home dual 500 MHz G4:
a_type = 22 a_val = 0x16
a_type = 22 a_val = 0x16
a_type = 19 a_val = 0x20
a_type = 20 a_val = 0x20
a_type = 21 a_val = 0x0
a_type = 16 a_val = 0x9C000000
a_type = 6 a_val = 0x1000
a_type = 17 a_val = 0x64
a_type = 3 a_val = 0x10000034
a_type = 4 a_val = 0x20
a_type = 5 a_val = 0x6
a_type = 7 a_val = 0x30000000
a_type = 8 a_val = 0x0
a_type = 9 a_val = 0x10000350
a_type = 11 a_val = 0x130
a_type = 12 a_val = 0x130
a_type = 13 a_val = 0xA
a_type = 14 a_val = 0xA
CPU does have Altivec
a_type = 16 (AT_HWCAP) holds the "arch dependent hints at CPU capabilities".
Here are the CPU features as defined by asm/cputable.h:
#define PPC_FEATURE_32 0x80000000
#define PPC_FEATURE_64 0x40000000
#define PPC_FEATURE_601_INSTR 0x20000000
#define PPC_FEATURE_HAS_ALTIVEC 0x10000000
#define PPC_FEATURE_HAS_FPU 0x08000000
#define PPC_FEATURE_HAS_MMU 0x04000000
#define PPC_FEATURE_HAS_4xxMAC 0x02000000
#define PPC_FEATURE_UNIFIED_CACHE 0x01000000
So for my home dual 500 MHz G4, 0x9C000000 translates to the following
features:
32, HAS_ALTIVEC, HAS_FPU, HAS_MMU
That seems to be a good sanity check on the code.
I then did a run on a 300 MHz G3:
a_type = 22 a_val = 0x16
a_type = 22 a_val = 0x16
a_type = 19 a_val = 0x20
a_type = 20 a_val = 0x20
a_type = 21 a_val = 0x0
a_type = 16 a_val = 0x8C000000
a_type = 6 a_val = 0x1000
a_type = 17 a_val = 0x64
a_type = 3 a_val = 0x10000034
a_type = 4 a_val = 0x20
a_type = 5 a_val = 0x6
a_type = 7 a_val = 0x30000000
a_type = 8 a_val = 0x0
a_type = 9 a_val = 0x1000039C
a_type = 11 a_val = 0x130
a_type = 12 a_val = 0x130
a_type = 13 a_val = 0xA
a_type = 14 a_val = 0xA
CPU doesn't have Altivec
One thing I'm not sure about is if the auxv_t typedef needs to be
different for PPC64.
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.
-Bill
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-03-08 8:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-08 2:02 Runtime Altivec detection Bill Fink
2003-03-08 2:11 ` Hollis Blanchard
2003-03-08 8:04 ` Bill Fink [this message]
2003-03-08 18:21 ` Nathan Ingersoll
-- strict thread matches above, loose matches on Subject: below --
2003-03-09 4:01 Albert Cahalan
2003-03-07 16:47 Nathan Ingersoll
2003-03-07 17:24 ` 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
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=20030308030440.39fcdc90.billfink@mindspring.com \
--to=billfink@mindspring$(echo .)com \
--cc=hollis@austin$(echo .)ibm.com \
--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