P122 grows the shadow ROB model to four entries. The point is not
performance; it asks whether the current backend can keep more than one
renamed destination live once the container is available.
check
result
Verilator build
PASS
BusyBox shell workload reaches P122-FILE-OK
PASS
ROB occupancy counters emitted
PASS
Hardened layout
NOT RUN
ROB / PRF counter
value
ROB capacity
4
ROB max occupancy
1
ROB allocs
59,300,128
ROB commits
59,299,949
ROB flushes
179
ROB full-wait cycles
0
missing commit events
0
occupancy-0 cycles
135,022,896
occupancy-1 cycles
83,993,890
occupancy-2/3/4 cycles
0
max live physical registers
33
metric
P121
P122
shell window cycles
64,541,922
65,109,744
S_FETCH cycles
7,622,048
7,628,977
S_MEM cycles
27,719,218
27,785,996
This is a useful negative result. A bigger ROB ring does not create
backend overlap by itself; the current FSM still dispatches and commits
one destination at a time. The next backend rung needs a dispatch/issue
split before the ROB can become meaningfully occupied.