Re: Tonights Tradeoff - Background Execution Buffers

On 2024-09-26 10:11 a.m., MitchAlsup1 wrote:

On Thu, 26 Sep 2024 8:13:12 +0000, Robert Finch wrote:
 

On 2024-09-24 4:38 p.m., MitchAlsup1 wrote:

On Tue, 24 Sep 2024 20:03:29 +0000, Robert Finch wrote:
>

Under construction: Q+ background execution buffers for the block memory
operations. For instance, a block store operation can be executed in the
background while other instructions are executing. Store operations are
issued when the MEM unit is not busy. Background instructions continue
to execute even when interrupts occur. The background operations may be
useful for initializing blocks of memory that are not needed right- away.
When the operation is issued a handle for the buffer is returned in the
destination register so that the status of the operation may be queried,
or the operation cancelled.

>
This is how My 66000 performs:: LDM, STM, ENTER, EXIT, MM, and MS.
Addresses are AGENED and then a state machine over in the memory
unit performs the required steps. {{Not usefully different than the
divider performing the individual steps of division.}} While the
unit performs its duties, other units can be fed and complete
other instructions.
>
You just have to mark the affected registers to prevent hazards.

>
Q+ releases the registers right away, so things can continue on.
Q+ captures the register values at issue then does not modify the
registers. Did not want an instruction with three updates happening. It
keeps track of its own values. In theory anyway. Have not got to testing
it yet. A status operation might be used to query the final operation
results.
>
Altering Q+ to use 64-bit instructions and 256 registers instead of
supporting a vector instruction set. Two pipeline stages can be removed
then and it is a simpler design. Code density will decrease <200%.
Relying on software to assign registers for vectors.
>
Also adding a predicate field to instructions. Branches are horrendously
slow in this simple implementation. It may be faster to predicate a
dozen instructions.

 The depth of predication should be such that if FETCH will "get there"
by the time the branch "resolves" that number of instructions should
be predicated.

******
The circular list namer used to supply register tags turns out to impact performance more than anticipated. It stalled the machine 200+ times in 3,000 instructions, costing almost 10% in performance. It looked great on short runs of instructions, but being able to get longer runs, not so good. I had guessed that stalls would be a fraction of a percent.
So, a fifo based name supplier was written, it stalled the machine 22 times in 1,600 instructions. Much better than the circular list. But there may be yet a bug in the name supplier as far as I know it should not stall the machine at all, as only available registers should be in the fifo. There is a check to ensure that the register tag from the fifo is in fact an available one, and that seems to be failing occasionally. Still tons of bugs in the CPU.
There was a trick to the fifo based renamer. Four fifos are each loaded with ¼ of the register tags at reset. But when the registers are freed up the tags could be placed on any fifo. There was the potential that one fifo would get all the free registers. So, a rotator was placed on the fifo inputs to try and distribute the free registers evenly amongst the fifos. Fifos had to be a power of two in size, so each can hold all the register tags. The CL renamer has a lot simpler structure.