Using /f 3 to start up the emulator and running a typical app on that emulator gets me a 0xC000001D on
clz r2, r6
4.1.12 CLZ
:
Architecture version
Version 5 and above
I don't remember this happening in the original emulator. I ran it again in the original emulator and it died a similar death, but I can't be sure the correct (non-beta) DLLs are being used since I have 8.0.60317.00 (v2 beta) hooked up/registered, even though I started up the original vs8 emulator to run the app (outside of the debugger). Double-wide loads and dsp instructions seem to work, just not the CLZ (I haven't looked beyond these), so it's not a /f not making it through problem.
And of course the code works fine on any real device using any current CPU. It's only the emulator that objects. Any plans to fully handle the available-since-1999 ARMv5 architecture
/f 3 no go on CLZ - 0xC000001D (v2 beta)
F. Gsell
That's a valid point, but the /f 3 switch turns on armv5 emulation. Or, as I recall, it used to work well enough for all the instructions I used, but it was last October (05) that I would have done this (long time). As I wrote, it works now for double-wide loads, and the dsp extensions (these are all v5 architecture instructions), but not clz. armv4 dates to 1996. armv5 was vapo-introduced in 1999. My four-year-old iPAQ 3970 runs it fine. You wouldn't expect a debugger to be released that didn't support mmx, or sse, or sse2, etc, or any of the other post-pentium instructions, would you The compiler defaults to using none of these, yet the debugger at least understands them, and runs your code, sse2 or whatever, and all of them, not a select subset. The arm compiler has various v5 switches, to generate armv5 code: /QRarch5, /QRarch5T, /QRxscale, /QRxscalesched, and the assembler of course can generate everything you want it to. Take a look at armintr.h in recent sdks, going back to at least ppc 2003's sdk. The arm compiler generates armv5 code from those intrinsics.
Anyway, it's got to be broken. It's awfully short-sighted to not work -- it's awfully short-sighted to require using a command-line switch (/f), but it may be a dumbing-down thing (I can't see the reasoning for hiding it other than that). The switch is documented, last I looked, in the device emulator manager's .chm (menu: Help, ...).
donkaiser
Not strictly speaking my area, but I was under impression this was ARMV4/4i emulator. In fact Windows Mobile (of which this is the emulator) does not list other ARM CPUs (meaning of course command sets) as supported platforms. I'm sure that XScale has some commands that this emulator does not recognize either. V4 is just a greatest common factor of the various ARM CPUs on the market. It's kind of like most of the C++ compilers by default generating 386-compatible code.
You are of course welcome to write code that uses new instructions, but you will need a piece of real hardware to test it.