Re: Banked register files

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Tue, 27 Aug 2024 23:51:59 +0000, Brett wrote:
 

MitchAlsup1 <mitchalsup@aol.com> wrote:

On Mon, 26 Aug 2024 21:10:48 +0000, Brett wrote:
 

Brett <ggtgp@yahoo.com> wrote:

Robert Finch <robfi680@gmail.com> wrote:

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

Brett <ggtgp@yahoo.com> wrote:

MitchAlsup1 <mitchalsup@aol.com> wrote:

 
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.

 
No reply’s, so I figure y’all are under NDA. ;)

 
It has been well known since mid 1990s that most loops end up with a
single
or dual stream of self dependent instructions and few loop dependencies
{mostly the loop index itself}. This leads to instruction dependency
graphs (and execution times) that look like::
 
| LD  |
| LD  |
|    FMUL    |
|    FADD    |
| STA |                         | STD |
| ADD |
| CMP |
| BV  |
------------------------------------------------------------
| LD  |
| LD  |
|    FMUL   |
 

 
To even out the cluster load you would want the compiler to unroll once,
first bank second, then second bank first.
 
Can also be done without compiler by mapping the links on the second
pass of a loop.

 
The above is done with simple reservation stations and no compiler work.
 

I am assuming clusters or banks as naming and issue width continue
growing.

 
Once you start doing reservation station machines, your 72-entry banked
register file needs to have the RSs watch 72 results instead of just 32.

ALU’s are cheap, so each bank has its own set.
You can forward and complete twice as many results.

The traditional problem of banking is a one cycle delay crossing banks, a
compiler can fix that, a CPU cannot on first pass.