Now let's think how to use the intra-bundle interactions to determine whether two instructions are in the same bundle.
The most universal approach is to use $c read behavior - initialize a $c bit to 0, choose the first instruction so that it'll set the bit to 1 (or the other way around), choose the second instruction so that its behavior depends on the $c bit. Here goes:
This covers all cases except the first instruction being vector (vector instructions don't set $c). Two cases can be tested using $v multiple write behavior:
The one remaining case is first instruction being vector and the second being branch - there seems to be genuinely no way to check for interaction in this case. We'll have to rely on transitivity here - but we won't be able to distinguish between a VB bundle and V + B bundles.
So let's write a program using all that to determine bundling behavior. We'll limit ourselves to 8-instruction samples (that should be enough let us notice if position in the stream makes a difference, but ), and go through all 4**8 (65536) combinations of A/S/V/B instructions (we could try to prune uninteresting variations, but it's more work than it's worth). For each of these combinations, we'll launch 7 tests to check whether instructions i and i+1 are in the same bundle or not (skipping over VB clusters appropriately). This results in 65536 * 7 tests - that's a lot, but managable.
There were no surprises when writing the test, and the results are quite simple:
This aligns nicely with branch targets being aligned to 4 words - this makes sure that you can't branch into what would otherwise be the middle of a bundle.
That's all there is to bundling. Next step - branches and their delay slots.
Elapsed time: 3h.Share on Twitter Share on Facebook