COMP.ARCH---------------- < Пред. | След. > -- < @ > -- < Сообщ. > -- < Эхи > --
 Nп/п : 77 из 100
 От   : BGB                                 2:5075/128        29 сен 23 22:18:25
 К    : MitchAlsup                                            29 сен 23 06:23:05
 Тема : Re: Misc: Another (possible) way to more MHz...
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 1@dont-email.me> d83cf2a4
@REPLY:
<7cfb10ca-e386-4d20-b9a9-a4bc1034cf5cn@googlegroups.com> 3beda4ef
@REPLYADDR BGB <cr88192@gmail.com>
@REPLYTO 2:5075/128 BGB
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<6zCRM.67038$fUu6.58754@fx47.iad> 1@dont-email.me>
<b9675661-624b-4acf-93b0-5e44a55fa95fn@googlegroups.com> <7cfb10ca-e386-4d20-b9a9-a4bc1034cf5cn@googlegroups.com>
@TZUTC: -0500
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.1
@TID: FIDOGATE-5.12-ge4e8b94
On 9/29/2023 6:53 PM, MitchAlsup wrote:
> On Friday, September 29, 2023 at 1:03:02 PM UTC-5, Timothy McCaffrey wrote:
>> On Friday, September 29, 2023 at 1:07:47 PM UTC-4, BGB wrote:
>>
>>> I had considered possibly redesigning the pipeline at one point to allow
>>> a different mechanism for handling L1 misses. Namely marking registers
>>> for missed loads as "not ready" and then stalling the Fetch/Decode
>>> stages if the bundle would depend on a not-ready register (injecting the
>>> fetched data back into the pipeline once the load completes).
>>>
>> I think you just re-invented the CDC 6600 register scoreboard.
>> - Tim
> <
> Not quite:: CDC 6600 scoreboard scheduled the beginning of instruction
> execution and also the end of instruction execution {{in contrast Thomasulo
> only schedules the beginning of instruction execution}}
> <
> There are "all sorts of" mechanisms that provide RAW interlocking.

As-is, it is a blob of logic something like (psuedocode):
   needStallRs =
((id2IdRs == exA1IdRn) && exA1Held) ||
((id2IdRs == exB1IdRn) && exB1Held) ||
((id2IdRs == exC1IdRn) && exC1Held) ||
((id2IdRs == exA2IdRn) && exA2Held) ||
((id2IdRs == exB2IdRn) && exB2Held) ||
((id2IdRs == exC2IdRn) && exC2Held) ||
((id2IdRs == exA3IdRn) && exA3Held) ||
((id2IdRs == exB3IdRn) && exB3Held) ||
((id2IdRs == exC3IdRn) && exC3Held) ;
   needStallRt =
((id2IdRt == exA1IdRn) && exA1Held) ||
          ...
   ...
   if(id2IdRs == REG_ID_ZZR)
     needStallRs = 0;
   if(id2IdRt == REG_ID_ZZR)
     needStallRt = 0;
   ...

   needStallInterlock = needStallRs || needStallRt || ...

Where the interlock stall mechanism causes the PF/IF/ID1/ID2 stages to 
stall, with NOPs being forwarded into EX1.


The ready bit would likely be handled by internally expanding the 
register fields, and then using one of the bits to signal whether or not 
the value is ready to be used or is still waiting for an associated 
operation to finish.

But, with ready flagging (and a mechanism to inject the values later), 
it could be possible in theory to eliminate the need to stall the EX 
stages (and possibly a way to "hide" some of the L1 misses).

...

 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.1
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх