[gynt]

Stack slot assignment is not declaration order. It is reference weight per byte, and this PR documents the mechanism, the evidence, and a tool to read it.

Where this comes from

The bundled MSVC1400-SP1 toolchain is the compiler that reproduces the game's codegen (c2.dll, Microsoft (R) Optimizing Compiler Version 14.00.50727.762). Microsoft still publishes c2.pdb on its symbol server, which names every function in the optimizer, and c2.dll's own fatal-assert path leaks its source paths (F:\SP\vctools\compiler\utc\src\P2\stack.c, P2\color.c, P2\regasg.c, 66 files in all). So the backend's stack colorer could be read directly rather than guessed at.

ColorStackElements (P2/stack.c, named by the assert at line 1372) builds one 28-byte record per stack element holding the local's size rounded up to 4 and its accumulated reference weight, sorts the records with StkColorCmp, and then hands out offsets in that order:

// StkColorCmp, c2.dll 14.00.50727.762
if (a->class != b->class)                  // byte at +0x18, unsigned
    return (a->class > b->class) ? (dir ? +1 : -1) : (dir ? -1 : +1);
ka = (a->weight * 1000) / a->size;         // +0x0C scaled, divided by +0x08
kb = (b->weight * 1000) / b->size;
return ka == kb ? 0 : (ka >= kb ? +1 : -1);

Evidence

planToBuyWhenLowOnResourceAndSnoozeBuildings has fourteen int allowX = 1; locals. Eleven get colored, and they come out exactly in descending reference count from the lowest esp offset upward — 5 5 4 4 4 4 4 3 3 3 — with their declaration positions scrambled (the 4th declared sits between the 8th and the 9th, the 1st sits last).

Three checks on top of that correlation:

• Perturbation. Adding a single reference to one local reshuffled the whole table — another local left the stack for a register entirely, a third took over a vacated slot — and the new layout was again exactly monotone in weight (5 5 5 4 4 4 4 3 3 3).
• Renaming is inert. allowQuarries → zzz and allowWoodcutters → aaaaaaaaaa, inverting both the alphabetical order and the lengths of an adjacent equal-weight pair, left the function byte-identical. The comparator never looks at a name.
• The model was read out of the comparator before the data was collected, so this is a confirmed prediction rather than a fit.

What changes for day-to-day work

• A slot-order mismatch means our locals carry different reference counts from the original's — look for a read the original has and we do not. It is not a declaration-order problem, which is why every declaration-order hypothesis for the Map::Units::UnitsState frame mismatches came back a tie.
• Weight ties are left to the order the symbols arrive in, permuted by QSortColors, an unstable quicksort. That is exactly why perm_decls.py took assignSelectionToKey 95.9% → 100% once and does nothing in most functions. The README and perm_decls.py's docstring claimed declaration order assigns slots; both are corrected to say it only decides ties.
• Locals with disjoint live ranges share a slot (writeMapOrSaveFile puts eight locals on the first parameter's slot), so a slot count is not a local count — diff_slots.py's note is qualified accordingly.
• A local can be placed on the slot of a parameter that is already dead. That is where Ghidra's "repurposed parameter" rendering comes from, including playerID = 0 used as a loop counter in aiRecruitUnits. It is the compiler, not the original source; transcribing it back cost 7 points.

slot_weight.py

Compiles one file with /FA and reads MSVC's own _name$ = N symbol table, so the local-to-slot mapping is observed, not inferred from the diff. It prints each local's reference count, weight, inferred size and weight per byte against its slot, flags shared slots and dead-parameter reuse, and with a reccmp run available names the first position where the original's slot census disagrees with ours.

Honest limits, which the docstring states: the primary key — the class byte at +0x18 — is not decoded, so arrays and address-taken locals interleave for reasons the tool cannot explain (wrapTextIntoLines is a worked example of a non-monotone report). The weight itself is approximated as references × 10 per loop nesting level, where the compiler uses real block frequencies from CgAnnotateEdgeWeight. Treat a non-monotone report as a hint about which local is light or heavy, not as a layout prediction. --reorder sorts declarations by descending weight and can therefore only decide ties — one cheap variant to measure, not a repair.

Register assignment — which callee-saved register receives which value, and the push order — lives in P2/regasg.c and P2/color.c and is untouched by this; that is the other half of alloc-only and remains open.

Testing

slot_weight.py was exercised on playSFXAtLocation, setupWorkshopProductionType, writeMapOrSaveFile, wrapTextIntoLines and planToBuyWhenLowOnResourceAndSnoozeBuildings. Documentation and one new tool only — no reimplementation source, headers or build files are touched, so no function's match percentage can move.

🤖 Generated with Claude Code

https://claude.ai/code/session_012yZukvLckY9Pd4jxzqcLRq