ARM Macs

Hi,
How much of a problem will it be to get Fire running on an arm mac ?

Cheers,
John

We have experience with arm/aarch64 on iOS. However we don’t have any hardware or even info yet as to this new target. Until we do, it’s going to be very hard to answer this question.

There’s actually a few steps top this, none pf which seem insurmountable.

  1. Supporting Mac/arm64 as a target platform
    a) Import .fx files
    b) toolchain tweaks
    c) compiler/linker tweaks
  2. Build Fire for Mac/arm
    a) build Fire itself
    b) get Mono/arm, boot for embedding and to run the compiler
  3. Testing on actual hardware

I expect most of (1) to be trivial; in fact I’ve been doing a lot of prep work and planning for it already, and a lot of the toolchain is intrinsically ready for arm by virtue of (a) having arm as a iOS target and (b) having multi-architecture support (on iOS) already. the Mac just “happens” to only have one architecture right now, but making it have two is matter of a few lines of code.

If all goes well (and we never know, because Apple likes to break headers each year in other ways where I need to bother others for HI fixes) I’m expecting to have the frameworks for (1a) imported by tomorrow night — assuming we get an Xcode 12 with Mac/arm frameworks, of course).

I don’t expect (1b) or (1c) to be much work, assuming the ABI is compatible/based on either Mac.x86 our iOS/arm64, and not something else altogether (for example Mac/Catalyst uses iOS ABI, on x86_64; I’d expect Mac/arm to use Mac ABi, on arm ;).

There might be a scenario where we need an updated LLVM and or need to teak LLVM ourselves to bridge a gap, but to be honest I don’t think so.

So pretty much expect (1) to be a smooth ride and done within the week or so, barring any unforeseen surprises (which will be there :wink:

Ok, on to (2). (2a) is trivial once (1) is done. change the architecture in the projects, rebuild, presto-fat-finay-Fire that should run on arm and x86.

(2b) is the big question mark here, as I have not idea what the status there is, and we’ll need to wait for the Mono guys to officially support Mono on Mac/arm64. I know the core Mono does support it (coz Xamarin/iOS), but I expect work will need to be put in from their side to get mono running on arm.

Note that until the very day Apple ships ARM Macs to costumers, you will most likely not care about (2) at all; all that matters is (1), to let you prepare your own projects. If (2) takes longer due to Mono, I think she can enable remote Toffee and island/Darwin debugging from Fire

That leaves (3), which of course depends on whether (a) Apple ships developer kits for ARM support, (b) we can get our hands on one and/or (c) when an affordable/feasible official arm Mac ships (e.g. rumor today is that an 24" iMac will be among the first ARM Macs. I’m not gonna be buying and shipping an iMac to Curaçao, just to test ARM ;), so if if there’s no dev kit (or we cant get one, I’ll hold out for the first reasonable real Mac (i.e. one id actually want to use).

That said, (a) my money is on there being a dev kit and/or a reasonable laptop or Mac mini being among the first arm devices and (b) us being able to do 99.99% of the work without needing actual hardware.

it’s going to be a fun week.

—marc

2 Likes
HeaderImporter import --json=/Users/mh/Code/Elements/Frameworks/Toffee/import-Toffee-macOS-11.0-arm64.json ...

is running now :wink:

3 Likes

Will you be getting that new arm based mac mini ?

I applied, :crossed_fingers:t3:

2 Likes

2 Likes

I had checked the requirements for big sur and my 2011 mac mini isnt going to cut it anymore, so this does mean I am finally being forced to upgrade. :slight_smile:

1 Like

Fwiw, I didn’t use Big Sur for any of this, all Catalina :wink:

Is there a technical reason your sticking with mono rather than use .net core ?

Mainly that

a) I’d have to reinvent the entire architecture for how Fire interacts with the managed code (GitHub - remobjects/Marzipan: Easily embed Mono and managed code in your native Cocoa apps)
b) I don’t trust .NET Core at all to not break shit with every 0.0.x release
and
c) I’m not even sure if the compiler & remaining toolchain, at this stage, builds for .NET core

That said, Apple in the keynote announced they have patches ready top submit to Mono for arm64 support, from their side, so I don’t have any doubt that this will be usable soon.

1 Like

I didn’t realize Apple contributed to mono. I was just thinking >5 it didnt make much sense and everything was converging

me neither, but they made a point in the keynote about helping open source stuff to be ready ands called out a few frameworks, including Mono, as something they worked with to help m one to ARM and said they’ll have patches “within a few days”…

Possibly; after 5 is out I gotta have a look at where Mono is going. Another (preferred) option would actually be to get the parts of the compiler we need inside the IDE to build und Island, and do away with the managed layer altogether. But that’s a major undertaking I don’t see us having the time for anytime soon, as much as I’d like it :(.

1 Like

See also https://blogs.remobjects.com/2020/06/23/apple-silicon/

marc@Someones-Mac x86_64 % uname -s -m
Darwin arm64
marc@Someones-Mac x86_64 % ./MacConsoleApplication14
The magic happens here.
marc@Someones-Mac x86_64 %

1 Like

Does that mean you got the hardware from Apple ?

Afraid not :(. But I got access to someone’s else’s via SSH for some basic testing.