The C units test whether VU1 runs on its own thread, and whether it
runs instantly, through EMU_THREAD_VU1 and EMU_INSTANT_VU1. These read
two new bits of emu_hot, which emu_config_sync_hot sets from
THREAD_VU1 and INSTANT_VU1. emu_config_thread_vu1 and
emu_config_instant_vu1 are gone. They were out-of-line calls into the
C++ config, made on every VIF1 transfer, unpack, kick, SPR transfer
and VU1 program start. The settings behind both bits are under the
Cpu and Speedhacks groups that tests/hotconfig already audits, so a
write that skips the resync is caught there. The macros compare
against zero, because MSVC's C89 bool is an unsigned char.
The tests that drove the two accessors through stubs now set the bits
in their own emu_hot.
Vif_Unpack.c is UNPACK's setup, its partial-transfer gathering, the
interpreted unpack loop and the per-vector workers in C89. The workers
take the VIF state as arguments instead of choosing VIF1's or the VU1
thread's copy on every element written, so the loop resolves it once
and both units share one set of workers: VIFfuncTable is [mode][...]
now, half the code. The partial-transfer buffer moves out of the
recompilers' nVifStruct into vifUnpackBuffer, nVif is defined with the
recompilers, and the C++ is reached through dvif_unpack, mtvu_vif,
mtvu_vif_regs and mtvu_vif_unpack.
V4-5 elements are read as the halfwords they are, not as words that
are misaligned every other element and run two bytes past the last, and
an UNPACK whose restored state does not add up -- more data than the
buffer holds, or a partial transfer of a format or CL that sizes to
nothing -- is dropped instead of overflowing the buffer or dividing by
zero. tests/eevifunpack checks the unpackers against the previous C++
and covers those; tests/vif scores the C unit and its loop
(hwcycle.cpp, now built and with the table index corrected) against the
console captures.
The bug in the previous commit was possible because the table's layout is
implicit: VIFfuncTable's inner dimension is four blocks of sixteen, which
block is which appears only in UnpackModeSet's macro arguments, and a
caller that guessed wrong got a plausible function rather than a crash.
So the layout is now asserted. One S8 unpack of 0x88 separates all four
blocks -- signed gives ffffff88, unsigned 00000088, and either masked form
takes the column value -- so a reordering fails here, naming the block
that moved, instead of quietly in whichever caller disagrees. Moving the
signed masked block to the front is caught.
The audit for other instances came back clean. There are four indexed uses
of the two tables in the tree: the fixed one, and three of nVifUpk which
agree with each other -- the fill sites in x86/newVif_UnpackSSE.cpp and
arm64/Vif_UnpackNEON.cpp and the read in the unpack loop all use
usn * 32 + mask * 16. That table is self-consistent and was never wrong;
only the cross-use was.
Also checked and not scored: tests/dma/vif/basic.expected exercises the
FIFO, simple-DMA and chain-DMA transfer paths, and mskpath3.expected a
register write, so both need the DMA machinery running rather than a
function of inputs. Noting them so the next person does not re-derive
that.
libretroadmin