eMbedded Visual C++ ARM Compiler

Larry Bank posted this question in the web chat we had last week :


The current ARM compiler is pretty bad at producing fast code. Is the ARM compiler improving in eVC4 SP3?
The current ARM compiler has 2 major flaws and 1 minor flaw:

1) The REGISTER keyword is ignored. This is critical to producing fast code because the compiler does not always choose the right variables to keep in register.
2) The favor Fast vs. Small code options don't seem to work. I set it for fastest code and it adds extra branches everywhere to make the code smaller (and slower)
3) There is no way to specify CPU - specific optimizations (e.g. OMAP, StrongARM, Thumb, XScale).


I asked the compiler team and here's what they had to say.

1. The register keyword is only a *hint* to the compiler to help it generate better code, which was probably more useful in the days where compilers didn't aggressively optimize. But with more advanced optimizing compilers such as ours that assign registers to the variables based on information such as lifetime and number of uses, the compiler is expected to be able to do a better job of selecting registers on its own.  Supporting the effects of the REGISTER keyword has been deprecated.  The same language constraints still apply as mentioned in the link below.  If it were the case that the compiler had to honor the keyword as much as it could, the compiler could likely be impeded from generating more optimal code.

More info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang98/html/_clang_the_register_storage.2d.class_specifier.asp

2. Many improvements have been made in the ARM compiler optimizations. However, getting a code sample for this case may help us spot problems we haven't caught yet.

3. The design is to generate the best code for ARM vs. Thumb vs. XScale based on the three respective -QRxxx compiler flags. There are no known optimization opportunities for OMAP. In general, our compiler tries to maximize compatibility across the ARM family, and it usually turns out that any non-compatible optimization that favors a particular processor doesn't give a win in real-world average cases anyway. Finally, using the ARM assembler may be a useful tool for rewriting perf-critical code using specific hardware features.

[Author : James Pratt]

Comments (7)

  1. Mike Dimmick says:

    I’d just like to point out that most of us are still stuck on the eVC 3.0 compilers in order to support the large market of Pocket PC 2002 devices out there. Indeed, most of my software is still targeted against the Pocket PC 2000 SDK (although I work for a vertical-market ISV/subcontractor, so we tend to be a few versions behind what’s in the market).

    Is it in fact safe to target CE 3.0 devices using the wce420 compilers? Should I set, and get my colleagues to follow, the Directories > Executable options in eVC 3.0 to use the newer compiler versions?

  2. There is an – unsupported – way of using eVC4 to build for Pocket PC 2002 in http://msdn.microsoft.com/library/en-us/dnppcgen/html/evc4migration.asp. I’d encourage you to read that article to get a feel for other ways you can use both tools and one source base.

  3. Neelima says:

    Hi James ,

    You had mentioned that we could use the /QRfpe flag to get hardware floating point support. My compiler (eVC 4 ) says this flag is not supported in this release. Please let me know if there is an update somewhere using which I can use the hardware floating point support in the compiler.

    Thanks & regards,


  4. Tu Trieu says:

    I used eVC4 Sp4, it worked well with my pda 4700 in both release and debug mode, but with HTC P3300 (omap chip ) , it doen’t work in debug mode. It say …not ARM chip … pls tell me the way to solve my Problem

  5. santosh says:

    I want to get a eVC++ code which will work on an ARM compiler

Skip to main content