Register cross-reference with the ane-guide

[sbryngelson]

Saw your repo from the ANEForge issue. I did a byte-level RE of the M1/H13 ANE program format (https://ane-guide.readthedocs.io, arXiv:2606.22283), and a good chunk of it lines up with your REGISTER_PROGRMMING.md, so here's the cross-reference in case it helps finish that off.

Your offsets are into the BTSP buffer, mine are into the ZinAneTdHw image. The common/dimension block lines up with a constant +0x34, and two of your values are byte-identical to mine:

your reg (BTSP)	value	my field (image)	match
InDim @0x128	0x0001004d	Win@0xf4 / Hin@0xf6 (15-bit)	+0x34
Cin @0x134	0x01	Cin@0x100 (17-bit)	+0x34
Cout @0x138	0x01	Cout@0x104 (17-bit)	+0x34
TaskInfo @0x160	0x00100000	CommonTaskType@0x12c	+0x34
ConvCfg	0x5000a021	op-config word	exact
pad2	0x2041	kernel-common record (0x5021 -> 0x2041)	exact

A few things that might fill gaps:

• Cin/Cout are 17-bit (max 131071), spatial dims 15-bit. Those are the field maxima.
• Your ConvCfg 0x5000a021 is one of three op-config words I see; the others are conv 0x5042a063 and matmul 0x5000b021. One to sort out: I had 0x5000a021 labeled reduce-mean-class but you use it for relu/conv, so one of our labels is off.
• pad2 0x2041 is the kernel-common record (0x5021 -> 0x2041); matches the firmware program-manager log byte for byte on my end.
• I've got ~190 named fields across the 7 groups (kernel/common, dimensions, tile DMA, elementwise/planar, L2/texture, kernel-fmt/op-mode, L2-result), so the DMA/L2/PE blocks you're doing by hand are probably covered.

Happy to send a PR adding a cross-ref section to REGISTER_PROGRMMING.md, or just compare notes on the DMA/L2 offsets. Covers M1 through M5, so might help the M5/H17 work too.

[allbilly]

Thanks a lot. I have already printed out your 300page publication and will read it word by word. The byte level reverse engineering must be a lot of work, please also checkout the link to patent analysis in readme, could be useful to your research.

Currently, i have access to M1, M3 ultra, M4 hardware. Do you hv any benchmarks wish to run on my side?

[sbryngelson]

Thanks! And yeah, I'll read through Handley's patent stuff, hadn't seen that.

M3 Ultra is actually the one I can't get my hands on (I've got M1 and M4). Good one to have anyway since it's the dual-die part with way more NE cores, and it's the same chip as that 512-channel thing in maderix/ANE#42.

If it's easy: could you recompile a couple of the ops you already have M1 hwx for (conv, relu, gemm in hwx/tinygrad/) on the M3 Ultra and send me the .hwx? Same gen_mlmodel.py flow you used for those samples, just on the other machine. The BTSP buffer works too if pure-register runs there. One thing that matters: note the macOS version, since the format moves between OS releases (you saw that with mul_macos14 vs mul_macos26). I just want to diff the same op M1 vs M3 to see where the offsets and opcodes shift.

That'd nail down the M3 layout, which you'd need for pure-register on it anyway. And I can PR the cross-ref register section into REGISTER_PROGRMMING.md whenever you want it.

[allbilly]

sure, happy to generate the hwx and accept the PR, i just feel sorry to hv u read through the AI slop REGISTER_PROGRMMING.md, will clean it up later

[allbilly]

ADD and MUL hwx uploaded @5a3b700
other hwx ops are from tinygrad, source code not included there, need look into further

[sbryngelson]

Spent some time on the hwx files. Turns out coreml2hwx hardcodes TargetArchitecture = h13 in coreml_util.m, so it always compiles for M1 no matter what machine it runs on. Both your m3u_macOS15/add.hwx and m1_macOS26/add.hwx have cpusubtype 0x04 (h13/M1), so the M3U one is really an M1-targeted compile on the macOS 15 toolchain. The diffs between them are the OS/compiler version, not the chip.

mil_to_hwx in the same repo (mil/ subdir) fixes that: it takes -a and cross-compiles for any gen h13..h18 from one machine, so you can get the real M3/M4/M5 layout without owning the chips. I ran the same op through h13/h15/h17 (M1/M3/M5) with one compiler:

• cpusubtype: 0x04 (M1), 0x06 (M3), 0x09 (M5)
• the DMA base-address records move: M1 packs them 8 bytes apart, M3/M5 16 bytes apart (the aperture VAs 0x30004000/8000/c000 don't change)
• the M1 op-config word 0x5000a021 (ISA V7) isn't in the M3/M5 images (V8/V19), so the opcode encoding shifts between gens

Can send the cross-compiled hwx per arch or the script if it's useful for the register guide.