Re: [AD] CPU info changes

["Henrik Stokseth" <hstokset@xxxxxxxxxx>]

Bob <ohannessian@xxxxxxxxxx> wrote:

> > so what about a compromise? from the allegro docs i'd say the following
info
> > should be available in binary since they are the most likely to be used
in a
> > game:
> >
> > family.
> > capabilities (int32 bitflags):  fpu, mmx, 3dnow, sse, cpuid
>
>
> Agreed. But family will have to hacked to allow for the Pentium 4
(currently
> 0xF), the Hammer and the Itanium. The last two of which I can't find any
> docs about what is exactly returned by CPUID :/

i just got another idea you can have a look at. i'm still thinking about
ways to ease parsing, while keeping extendablility. :o)

what about providing the info from check_cpu() as a list of name, value
pairs? where both name and value is a string.

--- example implementation ---

void check_cpu(void);

typedef struct CPU_CAPABILITIES {
   char *name;
   char *value;
} CPU_CAPABILITIES;

int num_cpu_capabilities; /* global var. number of items in array. */
CPU_CAPABILITIES *cpu_capabilities; /* pointer to array perferably also
terminated by { NULL, NULL }entry. */

--- example of use ---

CPU_CAPABILITIES *item;

check_cpu();

for (item=cpu_capabilities; item.name; item++) {
   printf("name: %s value: %s\n", item.name, item.value);
}

--- which lists for example ---

MMX: true
SSE: false
Family: i586

etc...

if we also keep the integer with binary bitflags (mmx, sse) so that the
assembly code can easily check this i think we have a good implementation,
don't you? :o)

Sincerely Henrik Stokseth.
-----------------------------------------------------------------------
"Our hardware runs better without Windows" - BMW advertisement.
E-mail: hstokset@xxxxxxxxxx  Homepage: http://hstokset.n3.net