[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] New snapshot for EU_INC and EU_CMP



hi,

Michael Riepe wrote:
> 
> On Wed, Jul 31, 2002 at 06:31:04PM +0200, Etienne LABARRE wrote:
> > On Wed, Jul 31, 2002 at 01:33:18AM +0200, Michael Riepe wrote:
> > >
> > > CMP is supposed to be either 0 or -1: cmp(a, b) = a < b ? -1 : 0.
> > >
> > > MSB1 is supposed to return the *number* of the most significant `1'
> > > bit: msb1(0xffffffff) = 64, msb1(0) = 0. Currently it returns some
> > > strange bit mask. Likewise for MSB0.
> >
> > Idon't agree with you. The criteria for CMP unit for me is :
> > If A = B, then result is null, else result not null.
> 
> We have XOR for that, don't we?

exact.
If the combine mode is able to stand the width, a SIMD mask
is even possible (just do a MUX to select your data).

> The instruction we need is `cmpl', aka `CoMPare Less' (A < B).
> 
> > I think that is more simple, and permit to win one or more level
> > latency.
> >
> > But, my unit is not compliant to the manual. What must we correct :
> > manual or code ?
> 
> Since the semantics of scan/lsb/msb seem to have changed behind my
> back, we will have to discuss that here. CMP/MIN/MAX/SORT is wrong,
> however.

LSB and MSB are needed in some cases but these algorithm do not
justify an additional pipeline cycle on CMP. When POPC is implemented,
it is "cheaper" to run the result from LSB into POPC.
Giving an "integer" number of 1 bits was just pure convenience,
but the structure of the reduce-tree (and the tight pipeline)
force us to use another simpler approach.
I even agree that some parts of the manual are science fiction.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/