I'm also curious how you dealt with x18 register in the mac hosted PR.

In the Cocoa PR, the host-side Cocoa/Objective-C backend runs entirely within the Darwin host environment, where the host compiler (Apple Clang) naturally adheres to Darwin's ABI and treats x18 as the reserved platform register for libSystem/pthread context. On the AROS side, as per commit (

960216ed1f

), we don't force

-ffixed-x18

on generic AROS target code to maintain object compatibility across AArch64 targets. The host boundary calls into Cocoa/libSystem operate cleanly through the host bridge (

hostlib

/ native host thread context), so x18 is preserved and untouched across macOS system and display callbacks.

but what happens if AROS clobs x18 and calls Cocoa through HostInterface?

This is handled as follows: 1.

SAVEREGS

and

RESTOREREGS

macros preserve Darwin's full register array across AROS task switches. 2. The communication between AROS HIDD and Cocoa runs over lock-free atomic ring-buffers and a shared frame buffer avoiding unsafe cross-ABI pointer chases. 3. As noted in

960216ed1f

, keeping

-ffixed-x18

off generic AROS objects prevents ABI fragmentation, while the Darwin host boundary remains self-contained.

👍