Updated the schematic (at the bottom):
- "operand registers" renamed to "physical registers"
- 8 × 4 registers per unit
- All ALU units have three input operands
I do not call L2 registers physical registers because they behave very differently than physical registers in a traditional register-renaming CPU design -- you can't read/write them directly except in special L2 read/write instructions
I disagree. In common terminology, "physical registers" refers to all renamed registers.
The only practical difference here is that L2REGS incur an extra cycle of latency.
But it's your choice how to name them.
On architectures like x86 (which I'm designing the CPU to support as part of a later grant), almost every instruction sets flags, so having those flags as part of the same register the output is written to means we only ever have to track one renamed output per instruction, which simplifies the control logic quite a bit since it only requires one kind of register as well as needing quite a few less registers because physical registers are allocated for instructions' outputs, not inputs, so if we didn't have flags and data in the same register then each instruction would need 2 output physical registers allocated for it.
Related, I'm planning on floating-point physical registers being the exact same registers as the integer physical registers,
I disagree.
- Packing flags, GP, and FP into one physical reg file saves two rename tags but costs more in the execution unit: increased MUX complexity and higher bandwidth pressure.
- Scheduler work (latencies, dependencies, FU availability) remains; merging register classes doesn't remove that complexity.
- For high performance, it's usually better to keep separate banks and separate interfaces. Your stated goal is "high performance".
PowerISA v3.0B is the first version that's actually open, previous versions are not. I'm planning on basing it on PowerISA v3.1C. maddld (64-bit integer mul-add) was added in v3.0.
OK — added three‑input ALUs to the schematic.
ah, I only saw a PNG version on the forum, maybe Discourse auto-converts it to PNG or something. When I expanded the image on the forum, the "original" link is to a PNG file.
I posted PNGs for two reasons:
- They are more widely supported and easier to view.
- Posting a SVG requires a free documentation license.
By "free documentation" I mean a license that requires derived works to also provide the original (editable) format. The GPL does not guarantee that, and any license that does guarantee it is incompatible with the GPL.
See the problem?
If you can find a suitable license that meets the criteria, feel free to suggest one.
how about 8 per pair of unit input/output? though you can just have a box and call it "physical register file slice" or something without specifying how many registers there are.
You're unclear to me — the numbers don't match. I modified the image; please check whether it matches what you meant.
Numbers are hard to communicate in text, and it's difficult to map text to a schematic. That's why the schematic needs concrete numbers.
I'm against putting parameters or unspecified numbers in the schematic: it reduces readability and muddles timing. We should pick a target number of registers that we think is best and show that on the diagram.
We can add a note at the bottom of the image describing which numbers are parameterized.
Or add dual labels: one showing the parameter name, and a second showing a concrete default value.
The way I envisioned the L2 register file is it's only used when the CPU runs out of regular physical registers, which should be quite rare (if it's not rare, we need more physical registers to make it rare again).
The problem with that strategy is a high‑priority result may need a physical register, and if the physical file is full it can't be freed quickly by moving values to L2REGS.
If most physical registers already have copies in L2REGS, you can, with high probability, discard a low‑priority result from physical registers to make space for a high‑priority one.
Therefore, increasing L2 write bandwidth and keeping copies of most results in L2REGS improves instruction throughput.
EDIT: regarding "rare":
You can't simply increase the number of physical registers indefinitely to hold virtually EVERYTHING: all important results, FP, flags. Increasing the physical‑register count has real costs, especially for speed. This becomes even worse if the design needs more ALUs, i.e. (7+1) instead of (3+1).
Recommendation: increase L2REGS write bandwidth by splitting into two banks.
