Re: [f-cpu] delayed issue

[Yann Guidon <whygee@f-cpu.org>]

hi !

nico wrote:

> On Tue, 04 Mar 2003 05:49:07 +0100
> Yann Guidon <whygee@f-cpu.org> wrote:
>
> > hi !
> >
> > devik wrote:
> >
> > > http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf
> > >
> > > VERY interesting reading !
> > almost in the same vein :
> >
> > http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-06.pdf
> :) nice :) Devik and whygee discover the 2 same things.
>  
oops sorry i used the wrong address !

http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-09.pdf
(it speaks about coffee)



> > (don't look at the publication date too early)
> >
> > well, now it explains a lot of things i've read on their project
> > site.... they simply have fun with DARPA money.
> :) How could you consider those researcher... That's... amazing.
>  
i have visited MIT/AI lab once and i can tell you that the people i've 
seen are a bit more serious ...
(and they are DARPA-funded too)


> > > Simplicity also has advantages that silicon efficiency on its own
> > > does not; simpler architectures are faster to design,
> > > easier to test, less prone to errors and friendlier to
> > > compilers.
> > >      
> > This is why FC0 has no renamed registers, OOOE,
> > and other sophisticated control stuff.
> >    
> OOOC include some difficulties, too. 
>  
but i don't think it will consume 100k transistors for FC0,
and there are less pipeline stages dedicated to scheduling.

In fact, the whole point of 000C in FC0 is that
the scheduling is partly performed in parallel with a non-OOOC
standard pipeline. This makes jump and loop overhead small
and further reduces the need for prediction and speculative
execution.

> > Additionally, more complexity means more silicon area,
> > more dissipation, longer wires => more heat/dissipation,
> > more expensive and probably slower.
> > And control logic is certainly the least easy thing
> > to test in a chip. This is why i'm satisfied with
> > the current FC0.
> >    
> not me :) Not when you saw the 3r2w regifile because of 1 or 2
> instructions (like MAC). Not when you saw the mess of "special register"
> that should be memory mapped (with conditionnal memory movemement like
> not buffered, if needed). Not when you see the trap/expetion mess.
>  
1) 3R2W is necessary also for load and store instructions, otherwise 
it's not
possible to perform pointer update in the instruction.
2) If you map SRs to memory, you will face race conditions and 
synchronisation problems,
and protection will not be enforced on a register or register group 
granularity basis.
3) what mess ?


> Beside that, i had beleived that tomasulo was a quick and "easy" OOOE.
> But it was not. It's the "canonical" OOOE. So it will be a big mess. Use
> of tomasolu could be an idea with a all different core to reduice memory
> foot print (like the use of 2 register adress fields instead of 3) but
> the pipeline need to be shorted to avoid the udge number of comparator
> that is needed.
>  
Heh.
we are not IBM :-)

> nicO
>  
YG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/