[BUG] Write registers in one go

[Jackcuii]

A serious bug introduced #49, which causes days of time to localize.

This teaches us NEVER use AI/agent tools blindly in the key codes without clear specification.

I am considering revert the modifications in #49 to avoid any more potential problems.

[n0thingNoob]

It is because the modification cannot pass the histogram test. And it was changed back to write the operand immediately. It is not simply due to AI blindly modifying.

The issue is that the code generator groups instructions by index_per_ii (time_step % compiled_ii), not by absolute time_step or by dependency-free parallel bundles. In the histogram kernel, this causes operations with a real intra-tile RAW dependency to appear in the same instruction-group bucket. As shown in the graph, two ops are grouped together because both satisfy time_step % 5 == 0, but GRANT_PREDICATE depends on the value produced by DATA_MOV. The generated DFG confirms this dependency (15 -> 18).

That means the current codegen implicitly assumes that instructions within the same sync instruction group execute in order and that later ops can observe earlier writebacks in the same group. When the simulator was changed to collect all results first and commit them only at the end of the sync group, this assumption broke: GRANT_PREDICATE read the old value of $1, the loop exit/control condition stopped propagating correctly, and histogram got stuck in an infinite loop.

[n0thingNoob]

But since the semantics are correct, the histogram hang proves that batched sync writeback is incompatible with the current generated program/simulator contract.

[n0thingNoob]

the failure looks like a misalignment between the data operand and the predicate operand at GRANT_PREDICATE: they arrive in different logical steps, so the exit condition never becomes valid in the same firing.

Time 100:
ID=18 SrcOperand:"1(true)" PredOperand:"0(true)" -> Pred:false

Time 105:
ID=18 SrcOperand:"0(false)" PredOperand:"1(true)" -> Pred:false