Niall

Dammit, where's an intern to run simulations when I need one!

So chains out of order at a macro scale, simple fusion within a chain, optional cascading, and modest out of order within a fast clock cluster. Given few chains, can turn off clusters.

Why? timing slack in the execution pipeline. For simple instructions, can often find enough slack to have a cascaded "half cycle" ALUs back to back for higher throughput.

Frontend can do modest macrofusion of dependent instructions within a chain. Given entire chains, a cluster can do complexity-effective out of order issue with simple wakeup/select logic: only look at head of each chain. May peek at second instruction to see if simple consumer

Build heavily clustered microarchitecture. Very modestly out of order clusters, fast clock, and a bypass ring between them. Overall core is very wide by using several clusters. Front end races ahead, sends complete chains to successive clusters; chains bypass only at boundaries

Thought experiment: don't ask compiler to schedule for ILP, but instead schedule dependent chains of instructions linearly, with consumers as near to producers as possible, with no knowledge of fusion patterns etc. Add a few marker bits for chain start/end.

For high end cores, this is a pain. At the highest end, probably don't want compressed instructions at all given fast clock, so lose the code size benefit. Secondly, have to tell compiler to schedule certain instructions next to one another so the decoder can spot them.

Wonder if RISC-V architects will regret the macro fusion argument for parsimony in the ISA. For low-end cores, it's ok to depend on fusion for common idioms like indexed load. Can use compressed instructions to reduce code size, and treat two 16b instructions like one 32b