BT

ARMing .NET Developers for Windows 8

by Jeff Martin on Aug 29, 2012 |

One of the advantages of the .NET Framework and the Common Language Runtime (CLR) is that developers who target it benefit from the abstraction it provides from the underlying hardware platform. Andrew Pardoe, program manager of Microsoft's CLR team, has recently described some of the changes made to the framework that have enabled it to run on the ARM architecture. This move is more complicated than the switch to 64-bit computing, and Pardoe explains the differences.

Pardoe begins by observing that "...Although the .NET Framework was designed to be platform-neutral, it’s mostly been run on x86-based hardware throughout its existence", and as result there are a few areas of their code developers should examine when ARM execution is desired:

  • Weaker memory model, but stricter data alignment requirements
  • Differences in how function parameters are treated
  • Project configuration details under Visual Studio

Processors based on x86 architecture adhere to a strong memory model which ensures that "... guarantee that the processor will look like it’s executing most reads and writes in the same order that the program specifies them." This guarantee simplifies multithreaded programming. By comparison ARM processors do not make this guarantee as they reorganize code during during organization. The end result according to Pardoe is that existing multithreaded code may have latent bugs that have not been detected yet if this code has only been run x86-based machines.

Performance considerations for the CLR have caused Microsoft to limit how much the runtime enforces a strong memory model on ARM processors. While some changes were made, such as the "[insertion of] memory barriers at key points when writing to the managed heap to guarantee type safety...", for the best results Pardoe recommends developers use the volatile keyword where appropriate.

The CLR takes care of data alignment for in most cases, but there are situations where a developer can affect this:

"The first way is to explicitly specify the layout of a structure with the ExplicitLayout custom attribute. The second way is to incorrectly specify the layout of a structure passed between managed and native code."

Finally, most developers targeting the CLR can simply set their Visual Studio project to target AnyCPU, and the resulting code will be compatible with ARM, x86, and x64.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Describe the memory model! by M Vleth

It would seriously help if Microsoft would actually describe the memory model. The current 'specs' are just lacking the necessary details. There are some university driven articles out there who try to fill in the blanks but this stuff should be integrated in the msdn docs.

Take for instance the volatile keyword, how many developers know that a Write to volatile Field A followed by a Read to volatile Field B might be swapped in execution order?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT