Re: [f-cpu] delayed issue

[nico <nicolas.boulay@ifrance.com>]

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.

> (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.

> 
> Except for the "multistriped addressing" idea
> ( http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-03.pdf )
> i see nothing groundbreaking or worth caring.
> They also explore some SMT (Simultaneous MultiThreading)
> aspects in an interesting way but only in the beginning.
> ( http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-07.pdf  )
> 
> The rest is simply useless in a "classical general-purpose" processor.
> Their ARIES architectures use straight Harvard (split address spaces
> for instructions
> and data) which is not the best supported architecture under most OS
> and compilers .... and they do only consider MPP (massively parallel 
> computing)
> while F-CPU shall be able to work as "standalone".
> On top of that, it's highly object-oriented and their pointers are
> weird...
> 
> And here is a quote from
> http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-12.pdf :
> 
> > The Hamal Instruction Set Architecture was
> > developed over a period of more than a year by a
> > process which can fairly be described as the worst
> > sort of engineering. It is almost purely the result of
> > thought experiments and hypothetical debates. With
> > the exception of some preliminary assembly
> > programming and scattered ties to existing
> > architectures, it has benefited from little to no realworld
> > validation.
> 
> 
> However JPG got something right :
> 
> > 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. 

> 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.

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.

nicO

> 
> 
> >-------------------------------
> >    Martin Devera aka devik
> >Linux kernel QoS/HTB maintainer
> >  http://luxik.cdi.cz/~devik/
> >  
> >
> YG
> 
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/