SDL CPU info (new functions)

As I’m working with assembly, it becomes very nice to be able to detect
what features are available on the current platform.

So I’m adding an API to SDL to detect these. :slight_smile:

Please look this over and send me e-mail with CPU’s and features I’ve missed.
slouken at devolution.com

Thanks!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
-------------- next part --------------
/*
SDL - Simple DirectMedia Layer
Copyright © 1997, 1998, 1999, 2000 Sam Lantinga

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the Free
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Sam Lantinga
slouken at devolution.com

*/

#ifdef SAVE_RCSID
static char rcsid =
"@(#) $Id: SDL_copying.h,v 1.3.2.1 2000/03/16 15:20:37 hercules Exp $";
#endif

/* This file documents the CPU information functions in SDL /
/
NOTE: this information and API may change during SDL 1.1 development */

#ifndef _SDL_cpuinfo_h
#define _SDL_cpuinfo_h

/* The different known classes of CPU
A class of CPU is any set of CPU’s that share a common instruction set.
All of the CPU’s which run SDL should be listed here, as well as a few
that don’t yet run SDL.
*/
typedef enum {
SDL_CPU_CLASS_UNKNOWN = 0,
SDL_CPU_FLAGS_PSX, = 1024 + SDL_CPU_CLASS_UNKNOWN,
SDL_CPU_CLASS_X86, = 1024 + SDL_CPU_FLAGS_PSX,
SDL_CPU_CLASS_PPC, = 1024 + SDL_CPU_CLASS_X86,
SDL_CPU_CLASS_68K = 1024 + SDL_CPU_CLASS_PPC,
SDL_CPU_CLASS_SPARC = 1024 + SDL_CPU_CLASS_68K,
SDL_CPU_CLASS_ALPHA = 1024 + SDL_CPU_CLASS_SPARC,
SDL_CPU_CLASS_ARM = 1024 + SDL_CPU_CLASS_ALPHA,
SDL_CPU_CLASS_MIPS = 1024 + SDL_CPU_CLASS_ARM,
SDL_CPU_CLASS_VAX = 1024 + SDL_CPU_CLASS_MIPS,
SDL_CPU_CLASS_LAST
} SDL_CPU_CLASS;

/* The different known CPUs.
A CPU is a set of CPU models that share a complete unique instruction set.
These are defined so that each CPU is unique.

The actual values associated with the enumerated constants will change
as more CPUs are added to the list. Binary compatibility will only be
guaranteed as of SDL 1.2.0.
/
typedef enum {
SDL_CPU_UNKNOWN,
SDL_CPU_PSX1 = SDL_CPU_CLASS_PSX + 1,
SDL_CPU_PSX2,
SDL_CPU_286 = SDL_CPU_CLASS_X86 + 1,
SDL_CPU_386,
SDL_CPU_486,
SDL_CPU_PENTIUM,
SDL_CPU_PENTIUMPRO,
SDL_CPU_CELERON,
SDL_CPU_CELERONA,
SDL_CPU_PENTIUMII,
SDL_CPU_PENTIUMIII,
SDL_CPU_604 = SDL_CPU_CLASS_PPC + 1,
SDL_CPU_G3,
SDL_CPU_G4,
SDL_CPU_68K = SDL_CPU_CLASS_68K + 1, /
?? /
SDL_CPU_SPARC4 = SDL_CPU_CLASS_SPARC + 1,
SDL_CPU_SPARC5,
SDL_CPU_SPARC10,
SDL_CPU_SPARC20,
SDL_CPU_ULTRASPARC,
SDL_CPU_ALPHAEV4 = SDL_CPU_CLASS_ALPHA + 1,
SDL_CPU_ALPHAEV56,
SDL_CPU_ARM = SDL_CPU_CLASS_ARM + 1; /
?? /
SDL_CPU_MIPS = SDL_CPU_CLASS_MIPS + 1; /
?? /
SDL_CPU_VAX = SDL_CPU_CLASS_VAX + 1; /
?? */
SDL_CPU_LAST
} SDL_CPU;

/* The known useful CPU flags /
#define SDL_CPU_FLAGS_MMX 0x00000001 /
PentiumII MMX /
#define SDL_CPU_FLAGS_EMMX 0x00000002 /
Cyrix Extended MMX /
#define SDL_CPU_FLAGS_3DNOW 0x00000004 /
AMD 3DNow! */

#include “begin_code.h”
/* Set up for C function definitions, even when using C++ */
#ifdef __cplusplus
extern “C” {
#endif

/* Return the number of CPUs available */
extern DECLSPEC int SDL_NumCPUs(void);

/*

  • The following functions assume that all processors in a multiple-CPU
  • system are the same. If this is not the case, let me know. :slight_smile:
    */

/* Return the class of the system CPUs */
extern DECLSPEC SDL_CPU_CLASS SDL_GetCPUClass(void);

/* Return the type of the system CPUs */
extern DECLSPEC SDL_CPU SDL_GetCPUType(void);

/* Return the flags of the system CPUs */
extern DECLSPEC Uint32 SDL_GetCPUFlags(void);

/* Macros to check CPU flags */
#define SDL_CPU_HAS_MMX() (SDL_GetCPUFlags() & SDL_CPU_FLAGS_MMX)
#define SDL_CPU_HAS_3DNOW() (SDL_GetCPUFlags() & SDL_CPU_FLAGS_3DNOW)

/* Ends C function definitions when using C++ */
#ifdef __cplusplus
};
#endif
#include “close_code.h”

#endif /* _SDL_cpuinfo_h */

So I’m adding an API to SDL to detect these. :slight_smile:

Can anyone say API bloat?

You should put this in a separate library.

While you’re at it, remove the threading and timers, they don’t belong
in SDL, either :).

m.On Thu, Mar 16, 2000 at 08:24:31AM -0800, Sam Lantinga wrote:


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

I have some issues with the Sparc system defines:

    SDL_CPU_SPARC4 = SDL_CPU_CLASS_SPARC + 1,
    SDL_CPU_SPARC5,
    SDL_CPU_SPARC10,
    SDL_CPU_SPARC20,
    SDL_CPU_ULTRASPARC,

I work in a Sparc shop here, and have access to many sparc machines.
Each machine can be identified by two characteristics: Platform and
Architecture.

The Architecture is what we consider CPU version. It includes things
such as instruction set and memory management hardware.

Directly available to me I have the following architectures and
platforms available:

sun4u SUNW,Ultra-Enterprise
sun4m SUNW,SPARCstation-5
sun4m SUNW,SPARCstation-4
sun4m SUNW,SPARCstation-20
sun4u SUNW,Ultra-4
sun4u SUNW,Ultra-2
sun4m SUNW,SPARCstation-10
sun4u SUNW,Ultra-5_10
sun4d SUNW,SPARCcenter-2000
sun4u SUNW,Ultra-250
sun4d SUNW,SPARCserver-1000
sun4m SUNW,SPARCclassic

That is from a quick glance across some of the systems here. I think
that architecture is a better method of defining the SPARC cpu’s that
trying to add a platform for each.

Note that many of the platforms use identical CPUs, and that a single
cpu architecture (sun4m, for example) have 3 or 4 implementations, each
with their own oddities (micro-sparc2, hyper sparc, ect).

Jamie

So I’m adding an API to SDL to detect these. :slight_smile:

Can anyone say API bloat?

You should put this in a separate library.
Oh come on! And add yet another dependency to your programmes? One of the
things I love about SDL is that you don’t have to
download/configure/make/make install 5 or 6 bloody libraries just to get
an app to load.

Long live the confused,
Akawaka.On Thu, 16 Mar 2000, Michael Vance wrote:

On Thu, Mar 16, 2000 at 08:24:31AM -0800, Sam Lantinga wrote:

Bother, said Pooh as he was dumped from the Matrix.

The fact that you can selectively configure which parts of SDL you want to
use means that the API won’t be “bloated”. Use want you want, --disable
the rest.

MarcusOn Thu, 16 Mar 2000, Michael Vance wrote:

On Thu, Mar 16, 2000 at 08:24:31AM -0800, Sam Lantinga wrote:

So I’m adding an API to SDL to detect these. :slight_smile:

Can anyone say API bloat?

You should put this in a separate library.

While you’re at it, remove the threading and timers, they don’t belong
in SDL, either :).

m.


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

Michael Vance wrote:

You should put this in a separate library.

I actually wanted to bloat Hermes’ API with it as it already has code
that checks for CPU features - if anyone wants to add some missing code

  • you’re welcome :slight_smile:

While you’re at it, remove the threading and timers, they don’t belong
in SDL, either :).

The ANSI people should have defined a threading API while they finalized
the C++ standard (like the Java one e.g.). C++ seriously lacks one. But
besides this I think threading does fit very well into SDL.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

So I’m adding an API to SDL to detect these. :slight_smile:

Can anyone say API bloat?

You should put this in a separate library.

I thought about this, but SDL needs these features internally.
The MMX detection code enables faster blitters.
The threading code is used by the audio subsystem.
The timer code … well, SDL_Delay() and SDL_GetTicks() are used internally.

I would like to have these features inside SDL, if they are required for
building it, especially if they are very useful to other developers. :slight_smile:

Comments welcome. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Thu, Mar 16, 2000 at 08:24:31AM -0800, Sam Lantinga wrote:

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

The original PSX uses a full MIPS R3000 processor (only thing missing is
floating point coprocessor), and the PSX2 uses something like a MIPS R5900
(I think). It might be better to define the PSX* CPUs within the MIPS
class. When I’m building PSX related tools (binutils, gcc) the canonical
target name is “mips-sony-psx” and gas/gcc use the MIPS instruction set.
I’ll try to find more concrete info on PSX2 to make sure it’s MIPS.

So far I like what I see:)

Quick question: how will you detect the CPU type? Will you use a
combination of SDL configure options + asm detection routines? I would
assume CPU class would come from the options passed to SDL configure?

MarcusOn Thu, 16 Mar 2000, Sam Lantinga wrote:

As I’m working with assembly, it becomes very nice to be able to detect
what features are available on the current platform.

So I’m adding an API to SDL to detect these. :slight_smile:

Please look this over and send me e-mail with CPU’s and features I’ve missed.
slouken at devolution.com

Thanks!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

The original PSX uses a full MIPS R3000 processor (only thing missing is
floating point coprocessor), and the PSX2 uses something like a MIPS R5900
(I think). It might be better to define the PSX* CPUs within the MIPS
class. When I’m building PSX related tools (binutils, gcc) the canonical
target name is “mips-sony-psx” and gas/gcc use the MIPS instruction set.
I’ll try to find more concrete info on PSX2 to make sure it’s MIPS.

Okay, let me know what it should be.

So far I like what I see:)

Quick question: how will you detect the CPU type? Will you use a
combination of SDL configure options + asm detection routines? I would
assume CPU class would come from the options passed to SDL configure?

Yes. It could get very messy very quickly, and I don’t know how useful
the CPU information would be.

Who is interested scratching the CPU class/type code and just go with a
CPU flags routine that returns things like “MMX”, and “3DNow!”, etc.?

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

I thought about this, but SDL needs these features internally.

That’s nonsensical. Why would it be prohibitive to have it in a small
extern library that SDL depends on? SDL depends on stdio “internally”,
but that’s not a problem, is it?

The threading code is used by the audio subsystem.

Same here. A separate cross platform threading API that SDL depends on
would be cleaner.

The timer code … well, SDL_Delay() and SDL_GetTicks() are used internally.

And again.

I would like to have these features inside SDL, if they are required for
building it, especially if they are very useful to other developers. :slight_smile:

That’s because we have different ideas of what is considered
"useful". I consider small modules of code with clear purposes useful,
rather than monolithic APIs.

m.On Thu, Mar 16, 2000 at 09:42:36AM -0800, Sam Lantinga wrote:


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

The original PSX uses a full MIPS R3000 processor (only thing missing is
floating point coprocessor), and the PSX2 uses something like a MIPS R5900
(I think). It might be better to define the PSX* CPUs within the MIPS
class. When I’m building PSX related tools (binutils, gcc) the canonical
target name is “mips-sony-psx” and gas/gcc use the MIPS instruction set.
I’ll try to find more concrete info on PSX2 to make sure it’s MIPS.

Okay, let me know what it should be.

Yeah, the PSX2’s main processor is a MIPS R5900.

So far I like what I see:)

Quick question: how will you detect the CPU type? Will you use a
combination of SDL configure options + asm detection routines? I would
assume CPU class would come from the options passed to SDL configure?

Yes. It could get very messy very quickly, and I don’t know how useful
the CPU information would be.

Who is interested scratching the CPU class/type code and just go with a
CPU flags routine that returns things like “MMX”, and “3DNow!”, etc.?

I dunno, I kinda like the fact that you can figure out what machine you’re
running on at runtime – even though this would be a little redundant from
the --target option that was passed to configure.

As far as SDL_GetCPUType and SDL_GetCPUClass, I think it would be useful
to find out which CPU you’re getting info for. For example, in embedded
architectures like the PSX and PSX2, there is a “main” processor and any
number of coprocessors (3D processing, graphics output, etc.). In many
cases you have to write code for more than one of these "different"
processors.

I’ll get you more info on PSX/PSX2 if you need it, right now I’m late for
class :slight_smile:

MarcusOn Thu, 16 Mar 2000, Sam Lantinga wrote:

I thought about this, but SDL needs these features internally.

That’s nonsensical. Why would it be prohibitive to have it in a small
extern library that SDL depends on? SDL depends on stdio “internally”,
but that’s not a problem, is it?

Right, but you don’t have to DOWNLOAD stdio seperately! :slight_smile:

From what I can tell, the goal of the SDL library is to provide a very
fast low-level interface to graphics programming for games.

Adding features to SDL that help it accomplish it’s goals is in absolutely
no way “bloating” the API. It is providing SDL with the functionality it
needs to perform as fast as possible.

Making a seperate download for SDL_DetectCPU() would be silly.
It would be similar to removing the detection of MFC versus DirectX from
the base SDL library on the windows port and sticking it into it’s own
library.–
Brian Hayward

How do you plan to handle mixed-architecture machines?

i.e. * Mac 68k w/ 65c02 Apple ][e daughter card.
* Amiga 680x0 w/ PowerPC accelerator card
* Apple ][ w/ 8086 CPM card (okay… a little bit of a streach)
* Athlon and Alpha on same motherboard (is this doable?)
* Mac (68k/ppc) with 80[543]86 windows card…
* PC with 4 voodoo 4’s as graphics acceleration CPUs
* circa 2020 pc with bio-neural co-CPU…

My point is whether this is a can of worms that we want to open… (please
forgive my archaic/fanciful examples…)

-Loren

SDL_CPU_ALPHAEV4 = SDL_CPU_CLASS_ALPHA + 1,
SDL_CPU_ALPHAEV56,

There is also ALPHAEV6 and ALPHAEV67

/* The known useful CPU flags /
#define SDL_CPU_FLAGS_MMX 0x00000001 /
PentiumII MMX /
#define SDL_CPU_FLAGS_EMMX 0x00000002 /
Cyrix Extended MMX /
#define SDL_CPU_FLAGS_3DNOW 0x00000004 /
AMD 3DNow! */

I believe i have a document on how to detect it, but Alpha CPUs have what is
called MVI instructions which i belive stands for Motion Video Instructions,
which are sort of MPEG decoding functions. If I can find the link to the
document on it, i’ll post it.

The PowerPC’s now have the Altivec (sp?) stuff now also don’t they?

mike

Right, but you don’t have to DOWNLOAD stdio seperately! :slight_smile:

Of course you do. I’ve had to tell lots of people to install
glibc-devel in order to build programs.

fast low-level interface to graphics programming for games.

Audio, too.

Adding features to SDL that help it accomplish it’s goals is in absolutely
no way “bloating” the API. It is providing SDL with the functionality it

Of course it is, if those features could be useful to other people who
don’t want to carry around SDL’s baggage.

Making a seperate download for SDL_DetectCPU() would be silly.

Not at all.

It would be similar to removing the detection of MFC versus DirectX from
the base SDL library on the windows port and sticking it into it’s own

I don’t think so. A general purpose CPU identification and
capabilities detection library has a much wider scope of usefulness,
and is therefore a better candidate for being a separate library.

m.On Thu, Mar 16, 2000 at 12:35:16PM -0600, hayward at slothmud.org wrote:


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

Michael Vance wrote:

That’s nonsensical. Why would it be prohibitive to have it in a small
extern library that SDL depends on? SDL depends on stdio “internally”,
but that’s not a problem, is it?

This way SDL gets a wrapper for other libs more and more. Nothing bad -
I actually would find it very cool if SDLs and Hermes’ blitter code
could merge (sorry, I have to mention it all the time). But one thing
that bugs me already is the fact that I have to download and install a
dozen of files if I want to run a SDL app. Maybe this could be solved by
providing a single download or RPM that installs ALL SDL libs.

That’s because we have different ideas of what is considered
"useful". I consider small modules of code with clear purposes useful,
rather than monolithic APIs.

Well, the small modules idea is nice (I love the plugin system) but all
the modules should have a consistent API so it is easy to learn and the
general pattern is easily understandable (the purpose of STL).–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

This way SDL gets a wrapper for other libs more and more. Nothing bad -
I actually would find it very cool if SDLs and Hermes’ blitter code
could merge (sorry, I have to mention it all the time).

The main reason I hadn’t done it was because I wasn’t sure if SDL’s license
was going to remain LGPL. It will, so I’m more open to building hermes
support right in. However, I want a certain base functionality that is
available (though maybe not as fast) on all supported platforms.

But one thing
that bugs me already is the fact that I have to download and install a
dozen of files if I want to run a SDL app. Maybe this could be solved by
providing a single download or RPM that installs ALL SDL libs.

What? “a dozen of files”?

Well, the small modules idea is nice (I love the plugin system) but all
the modules should have a consistent API so it is easy to learn and the
general pattern is easily understandable (the purpose of STL).

I agree.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

In article <8ar9u5$ivm$1 at ftp.lokigames.com>,
“Mike” istan@alltel.net writes:

/* The known useful CPU flags /
#define SDL_CPU_FLAGS_MMX 0x00000001 /
PentiumII MMX /
#define SDL_CPU_FLAGS_EMMX 0x00000002 /
Cyrix Extended MMX /
#define SDL_CPU_FLAGS_3DNOW 0x00000004 /
AMD 3DNow! */

I would also add flags for at least the MTRR registers, the RTDSC instruction
and maybe the CPUID instruction …

Also I did not see anything to check whether the CPU has an FPU (most have
today, but well…)

Sam: FYI, MGL has some functions you can reuse to detect all that. Look
at the ~megastep/scitech/public/src/pm/cpuinfo.c file … They also use
NASM code to detect all that :-)–
Stephane Peter
Programmer
Loki Entertainment Software

“Microsoft has done to computers what McDonald’s has done to gastronomy”

Sam Lantinga wrote:

But one thing
that bugs me already is the fact that I have to download and install a
dozen of files if I want to run a SDL app. Maybe this could be solved by
providing a single download or RPM that installs ALL SDL libs.

What? “a dozen of files”?

SDL_net/image/mixer/ttf + SDL + SMPEG + game source - that is some work
:)–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

the modules should have a consistent API so it is easy to learn and the
general pattern is easily understandable (the purpose of STL).

I think that’s a pretty weak argument. None of SDL’s API calling
conventions, etc., strike me as purposefully consistent except in
their namespace wart. The ABI seems to break with some regularity.

There is a reason that Unix-style programming and development is so productive--it is built around the idea of small, independent programs, libraries, etc., that can be connected in interesting and efficient ways.

m.On Thu, Mar 16, 2000 at 07:57:24PM +0100, Daniel Vogel wrote:


Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire