Comparing the 6600-derived architecture to the traditional register-renaming/OoO architecture

One critical difference between the 6600-derived architecture and traditional register-renaming OoO speculative processors is that writes to any one particular ISA-level register max out at 1 per clock cycle (without special measures to improve that) in the 6600-derived architecture, whereas the register-renamed version can easily handle multiple such register writes per clock cycle since the register writes are spread out across multiple physical registers.

(Note from lkcl: 6600 Reservation Stations are "register-renaming" stations. unlike in the Tomasulo Algorithm, they're just not given "names" because Cray and Thornton solved a problem they didn't realise everyone else would have. See tomasulo transformation and http://lists.libre-soc.org/pipermail/libre-soc-dev/2020-October/001050.html However further investigation shows that this may be WaW hazard relate)

The following diagrams are assuming that the fetch, decode, branch prediction, and register renaming can handle 4 instructions per clock cycle (usual on Intel's processors for many generations). They assume that ldu can write the address register after 1 clock cycle of execution and the destination register after 4 clock cycles of execution (can be achieved by splitting into 2 separate micro-ops).

The following C program is used:

#include <stdint.h>

void f(uint64_t *r3, uint64_t r4) {
    uint64_t ctr, r9;
    ctr = r4;
    do {
        r9 = *++r3;
        r9 += 100;
        *r3 = r9;
    } while(--ctr != 0);
}

See on Compiler Explorer

It produces the following Power instructions (edited for style):

f:
    mtctr r4
.L2:
    ldu r9, 8(r3)
    addi r9, r9, 100
    std r9, 0(r3)
    bdnz .L2
    blr

Register Renaming

Renamed hardware registers are named h0, h1, h2, ...

The syntax ldu h7, 8(h5 -> h8) will be used to mean that the address read comes from h5 and the address write goes to h8

The register rename table starts out as following:

6600-derived

Notice how the WaR Waits on r9 cause 2 instructions to finish per cycle (5 micro-ops per 2 cycles) instead of the 4 per cycle for the Register Renaming version, this means the processor's resources will eventually be full, limiting total throughput to 2 instructions/clock.

For the following table: - Assumes that ldu instructions are split into two micro-ops in the decode stage. The address computation is denoted "#5.a" and the memory read is denoted "#5.m". - Assumes that a mechanism for forwarding from a FU's result latch to a waiting operation is in place, without having to wait until the result can be written to the register file. - "Av r3" denotes that the value to be written to r3 is computed and is available for forwarding but can't yet be written to the register file. - "SW: #4" denotes that the instruction is waiting on the shadow produced by instruction #4. - "Rf #5:r5" denotes that the instruction reads the result latch for instruction #5's new value for r5 through the forwarding mechanism.