Hi all,

I've been using fasmg for some AArch64/macOS work and ended up filling in a few gaps I ran into, with help from an AI coding assistant (Claude Code) doing most of the actual implementation under my direction. I want to be upfront about that rather than bury it, since I know opinions on AI-written code are mixed around here (fair enough) - so let me lead with how it was checked rather than just the "trust me" version:

• Every new instruction encoding was cross-checked word-for-word against Apple's own as/otool, not just hand-derived and hoped for. There's now a small regression script (verify_encodings.sh) that does this automatically, so it's not a one-time claim.
  
• Every example program actually assembles, gets ad-hoc signed, and runs on real Apple Silicon hardware (M1 Pro) - not just "it assembles without errors."
  
• A handful of real bugs turned up along the way (a fasmg quirk, a missing-rebase-fixups gap, Darwin's variadic calling convention surprise) and are documented rather than papered over.
  

What's in it, for anyone working on aarch64.inc or macOS targets:

1. Instruction set additions to packages/aarch64/iset: LSE atomics (LDADD/CAS/SWP family - mandatory on all Apple Silicon), pointer authentication, ARMv8.2 dot-product plus the newer ARMv8.6 USDOT/BFDOT/BFMMLA, SHA-512/SHA-3/SM4 crypto, BTI, and RNDR/RNDRRS register access. (Fun fact from testing: RNDR actually isn't implemented on an M1 - traps as illegal. sysctlbyname's hw.optional.arm.FEAT_* flags confirm it and are the right way to check this sort of thing rather than trying the instruction and seeing what happens.)
   
2. Native macOS/AArch64 Mach-O support in the x86 format/macho.inc - it previously only understood i386/x86_64. Getting a hand-assembled arm64 binary to actually execute turned out to be a real rabbit hole (missing MH_TWOLEVEL/MH_DYLDLINK header flags were the key to a mysterious kernel-level kill, and arm64 dyld turns out not to process the classic indirect-symbol-table binding scheme at all - needs real LC_DYLD_CHAINED_FIXUPS bind entries instead). It's all written up if anyone's curious or hits the same wall.
   
3. 51 small example/self-test programs under core/examples/arm64, going from bare syscalls up through functions, strings, floats, NEON, and the new M-series instructions, each checking its own output and failing loudly if something's wrong.
   

Known gaps, documented rather than hidden: no rebase-fixup support yet (so absolute pointers baked into static data aren't safe under ASLR - examples use array indices instead), and no variadic-argument support in the ccall helper (Darwin passes varargs on the stack, not in registers, which the generic calling helper doesn't know about yet).

Repo's here if anyone wants to poke at it: https://github.com/ppiecuch/fasmg

I'd genuinely welcome anyone more experienced with fasmg's macro internals taking a look - there are a couple of spots (the chained-fixups generation in particular) that work but feel like they're fighting the existing structure more than they should.[/b]