views:

892

answers:

4

Hello,

I'm looking for a way to differentiate at runtime between devices equipped with the new ARM processor (such as iPhone 3GS and some iPods 3G) and devices equipped with the old ARM processors. I know I can use uname() to determine the device model, but as only some of the iPod touches 3G received a boost in their ARM processor, this isn't enough.

Therefore, I'm looking for one of these:

  1. A way of detecting processor model - I suppose there's none.
  2. A way of determining whether ARM neon instructions are supported - from this I could derive an answer.
  3. A way of determining the devices total storage size - combining this with the already known device model could hackishly lead me to the answer.
  4. < ENTER RANDOM IDEA >

Thanks in advance :)

+4  A: 

One workaround I can think of, is detecting if OpenGL ES 2.0 is available, since the newer processors enable that.

There's an article at mobileorchard on how to do it.

pgb
Thanks, that's actually a pretty decent way of implementing this hack. The one drawback however is that the only way to figure if OpenGL ES 2.0 is available is by calling EAGLContext::initWithAPI and checking the return value, which means introducing OpenGL into my project. Anyhow, unless I find a better way, I might do just that.
yonilevy
Yes, I agree that's a shame, and probably a heavy operation just to determine a device capability.
pgb
+7  A: 

Not exactly what you're asking, but one easy solution is to build your application fat, so that it contains executable code for both ARMv6 and ARMv7. If you do this, the appropriate code will run on the processor automatically, and you don't need to do any runtime checking. Effectively, you're letting the loader do the runtime detection for you.

To do this, change the Architectures setting in your XCode project from "Standard (armv6)" to "Optimized (armv6 armv7)"

Then, in your implementation, you do this:

#if defined __ARM_NEON__
    // Code that uses NEON goes here
#else  // defined __ARM_NEON__
    // Fallback code without NEON goes here
#endif // defined __ARM_NEON__

There is a similar macro that you can use to check for (non NEON) ARMv7 features, which I can't remember off the top of my head.

If you really want to do runtime dispatch, take a look at the sysctlbyname function in libc. Specifically, I think that looking up the HW_MACHINE_ARCH parameter may prove useful to you.

Stephen Canon
I need to check whether sysctlbyname can provide me with the information I need. Unfortunatley I don't have an iPod with the new processor at hand so I can't. Did anyone try this? It can be the ultimate way, but it really depends on what is defined there.
yonilevy
Also curious if that is a reliable way - someone plz confirm if this works for iPhone (3GS) as well as on iPod Touch (3rd)
Till
The `__ARM_NEON__` macro will be defined by the compiler when targeting ARMv7 processors that have NEON (which includes both the 3gs and 3rd gen touch).
Stephen Canon
Sorry if the question in my comment was no clear. When asking about the reliability of "this", I was actually referring to the runtime-check, not the predefined macro/s.
Till
Except in very special circumstances, there is no reason to do the check at runtime. That said, yes, the API is available on both platforms, and can be used.
Stephen Canon
I beg to differ - if you need to check only for a small bit of code, making a fat binary will double your Mach-o executable size, while a runtime check won't. Unfortunately, sysctl(byname) doesn't work: hw.machine/HW_MACHINE actually returns the model (e.g. "iPod2,1") for unknown reasons, and hw.machinearch/HW_MACHINE_ARCH returns an error. Fortunately, I have found a way.
Pierre Lebeaupin
@Pierre: Generally speaking, executable size is a tiny, tiny fraction of the total size of an application. The bulk of the space on disk is consumed by graphics, sound, text, nib files, and other resources that are shared between multiple architectures. Although building fat may double the size of your mach-o binary, it usually only results in a tiny increase in overall application size, and is often worth the expense for the performance benefits that it confers.
Stephen Canon
A: 

I know this is crummy, but the best that comes into my mind is detect if the device supports video recording. Currently only the ARM7 based iPhone and iPod devices support it, hence its a legit way, I guess.

To do so, use UIImagePickerController's availableMediaTypesForSourceType in conjunction with isSourceTypeAvailable on kUTTypeMovie.

Till
+1  A: 

EDIT: I have withdrawn this answer, as it left out a glaring hole I realized later: what to do when we get an unknown subtype on some future hardware? THIS WAS NOT FUTURE-PROOF. Also, the uncertainty of the documented status of that API doesn't help, given Apple's zero tolerance on usage of undocumented APIs.

You should use Stephen Canon's answer and build your application fat. Reliable, future-proof runtime detection is not feasible at this time (to my dismay, I assure you).

Pierre Lebeaupin