Re: Banked register files

On 2024-08-22 5:58 p.m., Brett wrote:

Brett <ggtgp@yahoo.com> wrote:

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Mon, 19 Aug 2024 23:23:11 +0000, Brett wrote:
>

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Mon, 19 Aug 2024 21:46:07 +0000, Brett wrote:
>

Banked register files, a mental exercise at expanding the register file.
>

>
Four Banked register files, a mental exercise at expanding the register
file.
>
With three operand RISC you have you have three 5 bit register specifiers
using 15 bits.
>
If instead you have four banks of sixteen registers you have a 2 bit bank
specifier and three 4 bit register specifiers with one override bit for the
destination for 15 total bits, the same as a 32 register RISC chip. The
override bit specifies bank zero for destination, 64 total registers.
>
Two operand plus 16 bit offset instructions would need to sacrifice one bit
of offset. Four operand instructions would save two bits, quite useful.
>
Addressing can be done from any bank.
>
The compiler can handle large banks easily, simple dependency grouping and
if you need more than 16 registers for a single calculation you use the
Base override flag to total to the base registers. So you have two chains
that total in two banks and both write to the base registers where the last
total of the two chains are added.
>
Call and return parameters are in the base registers.
Simple code only uses base registers, or base plus one bank.

 On the mental status, having multiple banks means you can have multiple ALU
clusters and rename. You are no longer limited to 9 way rename and 12ish
way issue, but a multiple of that. The limits are load and store bandwidth,
and some added latency to coordinate.  Lots of money would get piled into
compilers to maximize even bank use.
 

Is this a good idea, i think so, but this is a mental exercise, it proves I
am mental. ;)
>
How does banked compare to high registers? Slightly better.
Intel could pull off something like this to one up ARM. A new fixed width
instruction set with a nice patent moat, and fits the x86 mindset.
>
Yes you can do
Rd,[Rbase+Rindex<<scale+LargeDisplacement]
Large displacements would be in extension words like My 66000.
Nothing stops you from doing add from memory, besides being costly in
opcode bits and die size.
>

  

Using BRAMs usually allows for a lot more registers than make sense in an architecture. Makes one wonder what to do with the extra registers. The MOV instruction can be made to use more bits for the register spec allowing transfers between banks of registers. Since MOV needs only two register specs instead of three, there are more bits available.
I have been experimenting with the idea of having a smaller register file so fewer encoding bits, and then making up for the small file by having more dedicated registers. For instance, 16 regs with 2 independent link register, eight condition code registers, and a stack pointer. That really gives over 20 registers, which might be enough for reasonable compiles.
I saw a design where there was an attempt to process basic blocks in parallel silos feeding functional units. It made use of fewer registers by holding data in pipeline registers instead of GPRs which it could do since some of the data for a basic block never goes outside the block.