COMP.ARCH---------------- < Пред. | След. > -- < @ > -- < Сообщ. > -- < Эхи > --
 Nп/п : 100 из 100
 От   : MitchAlsup                          2:5075/128        30 сен 23 16:39:31
 К    : Luke L                                                30 сен 23 02:43:02
 Тема : Re: RISCs and virtual vectors (was: Introducing ForwardCom)
----------------------------------------------------------------------------------
                                                                                 
@MSGID:
<4a3099a8-454d-4140-b3ce-6346a8288e31n@googlegroups.com> 150da48c
@REPLY:
<b2899a8d-5125-4b53-a461-137b6b04d4ecn@googlegroups.com> f2a41997
@REPLYADDR MitchAlsup <MitchAlsup@aol.com>
@REPLYTO 2:5075/128 MitchAlsup
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<memo.20230916204926.16432A@jgd.cix.co.uk> 1@dont-email.me> 1@dont-email.me>
<287e35a5-e78f-4ae2-bbb1-606f7bbdfe98n@googlegroups.com> <jwv5y3ydyqr.fsf-monnier+comp.arch@gnu.org>
<901e43e0-902d-4f5d-8ae4-22c570a94191n@googlegroups.com> <95KRM.207899$Hih7.53988@fx11.iad>
<72b6255a-e9b5-4549-b243-49ab8c49b064n@googlegroups.com> <2023Sep30.092454@mips.complang.tuwien.ac.at>
<ae46c988-7f46-4d66-9bae-8e5f03c86682n@googlegroups.com> <b2899a8d-5125-4b53-a461-137b6b04d4ecn@googlegroups.com>
@RFC-Message-ID:
<4a3099a8-454d-4140-b3ce-6346a8288e31n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Saturday, September 30, 2023 at 6:13:16 PM UTC-5, luke.l...@gmail.com wrote:
 > On Saturday, September 30, 2023, `MitchAlsup` via comp.arch
<comp...@googlegroups.com> wrote:
> > On Saturday, September 30, 2023 at 2:34:08 AM UTC-5, Anton Ertl wrote: 

> >> What do the additional instructions buy? 

> > Sequencing semantics--mainly in what does NOT need to be performed 
> > (the live-outs for example minimizes the work of exiting the loop).
<
> and i remember mmm 4 years back you said that it is less 
> hardware to have *one* looped LD/ST than to have hardware 
> make the attempt to spot that say 12 scalar LD/STs are 
> sequential/contiguous. 
<
Given one can see a LD or ST instruction and knowing that it is between
VEC and LOOP instructions, one can determine if the memory sequence
is "dense" or not. Dense memory instructions can be processed at cache
line width, and this allows the calculation instructions to be processed 
SIMD-style, otherwise one can always resort to GBOoO execution styles.
<
Were it not for the VEC and LOOP instructions, the problem is way harder.

> i designed some hardware to do that and for 12 LD/ST Reservation 
> Stations it has something mad like 10,000 wires incoming/outgoing 
> but only 4,000 actual gates. 
<
That is the classical trade off between Scoreboards and Reservation
Stations. {Imagine a 6-wide machine} The number of wires in the RS is 
proportional to the number of busses and the namespace of the values 
traversing that bus. Let us postulate that there are 6 FUs and a 128 register 
value namespace. So, every cycle 6 FUs send a 7-bit tag {42 wires move
per cycle}. Each of those 7-bit items must be compared to the desired value
{CAM} and CAMs eat power in order to make register data flow decisions.
<
Consider the SB alternative, 6 FUs and 128-wires each {768 total}. But here, 
only 6 wires move per cycle. Each of these 768 wires is compared to a 
single value (AND gate) in order to make register data flow conditions.

> l.
--- G2/1.0
 * Origin: usenet.network (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    
                                                                                
В этой области больше нет сообщений.

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