BT

Xamarin’s Rough Transition to 64-bit iOS/OSX

by Jonathan Allen on Nov 14, 2013 |

When Xamarin started their iOS project the devices were only available in a 32-bit mode, which meant 32-bit versions of NSInteger and CGFloat. When they started looking into 64-bit OSX they realized that their assumptions about those data types was wrong. Miguel continues,

We would need to audit all of our APIs to do the proper type mapping and we would break source code compatibility, with code like this:

var foo = new Xxx ();

int count = foo.GetRowCount ();

// oops, can not cast a long into an int.

When we combined source code breakage with the fact that Apple had a 32-bit compatibility story and we had some legacy libraries that depended on 32-bit only APIs meant that we were in no rush to move to a 64-bit world.

With the introduction of 64-bit only libraries in Mountain Lion they saw a need to change this design. It was further compounded by Apple’s decision to offer 32-bit and 64-bit versions of the iPhone 5. To deal with these new challenges Xamarin has created three new data types:

  • nint
  • nuint
  • nfloat

These new structs are defined as 32-bit or 64-bit depending on which platform the code is being compiled to. But there is more to the story than that. Primitive math uses special IL instructions for operations such as addition while user defined structs need to call the op_Addition method.

This can cause a small but noticeable impact in performance sensitive code. Since these types are so fundamental to working with native libraries, the AOT compiler was modified to reinterpret operations with these typee. Miguel continues,

The call op_Addition ends up being the same as the native ECMA CIL add instructions. The IL might look scarier, but the native code is identical.

Some may wonder why Xamarin didn’t just go with IntPtr, the CLR data type that supports platform-specific integers. Miguel writes,

We chose the names nint, nuint over the built-in IntPtr and UIntPtr, because they felt natural "native integers" as opposed to the cultural association that IntPtr has with pointer or a native token. Additionally, we did not have the equivalent native floating point type.

We chose to stay away from using the names NSInteger and CGFloat for a couple of reasons: the functionality is general enough that it might be worth using in Mono in places beyond Mac and iOS and because it feels like these are real VM supported types as opposed to some type definition or alias. In an ideal world, these would eventually be part of the C# standard.

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

breaking source code compatibility by Michael Paine

That might have been a bad example:

int count = foo.GetRowCount ();

..change to..

var count = foo.GetRowCount ();

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