iPhone detecting processor model / NEON support

Question

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 :)

Heddie

Good question! I just checked the Omap3 reference manual and the instruction set support bits in the coprocessor-registers aren't accessible from user-mode... – Hypoxanthine

To what end? It seems like whatever decision you're trying to make in your application, there's probably a capability that you could test for, rather than going at it sideways by processor model. – Muhammadan

I'm doing intensive calculations. I'm not sure what capability I could test for. I can measure the performance and adapt to that, which sounds like the good approach, but I'm afraid it's rather difficult for me under my circumstances. I find it hard to believe there's no way of knowing wheter neon instructions are available or not. – Heddie

Answer 1

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.

Danette

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. – Heddie

Yes, I agree that's a shame, and probably a heavy operation just to determine a device capability. – Danette

Answer 2

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.

Jugal

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. – Heddie

Also curious if that is a reliable way - someone plz confirm if this works for iPhone (3GS) as well as on iPod Touch (3rd) – Oneness

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). – Jugal

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. – Oneness

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. – Jugal

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. – Overwrite

@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. – Jugal

Answer 3

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).

Overwrite

Answer 4

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.

Oneness