Re: [f-cpu] Taking decision on the project

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

On Thu, 12 Dec 2002 21:24:30 +0100
nico <nicolas.boulay@ifrance.com> wrote:

> On Wed, 11 Dec 2002 11:23:21 +0100 (CET)
> devik <devik@cdi.cz> wrote:
> 
> > > It lack mutli-cpu support that's a big lack for a 2004 cpu !
> > > (ll/sc are for mono cpu system !)
> > 
> > I just read IA64 system manual, there are many MP issues discussed
> > along with examples ... Maybe it could help ..
> > 

Yes. Certainly, as a begin.

> > > Whygee propose to detect 2 alias maybe 3. Beside the fact that it
> > > will be a hudge piece of silicon, i beleive that's not acceptable
> > > for compiler. Finding all memory alias in C code will be such a
> > > mess ! Our recent Gcc expert could better said about that.
> > 
> > hmm if it is about me, I'm not gcc expert ;-) But I have to say that
> > gcc marks some register as they contain non-aliased data (if it
> > knows) but for majority pointers gcc is "not sure".

That's not the problem of aliased data but aliased pointed data. Each
register adresse are used as direct access to a memory, without really
checking the true adress. If 2 registers hold 2 times the same adress,
you will modify different memory buffer !

> > There are aliasing data attached to each memory reference which
> > contains type and parent (structure) of datum. Unfortunately
> > when I tested with some code snippets, many pointers have simply
> > [0 S8 A64] alias set so that they can't be distinguished by gcc.
> > 
> > > My proposal was to use the stream hint. That's what they are
> > > supposed to do : split memory stream, to avoid checking
> > > read-after-write memory hasard. If compiler didn't use them
> > > cleanly: shame on it :) That introduice 7 cache lines instead of
> > > 64, that's fewer but much easier to handle.
> > 
> > hummm, what problem addresses these things ? Memory RAW ? In
> > UP environment these should not occur AFAIK because all caches
> > are controled by single CPU and cache lines should not be aliased.
> > For MP why don't use acquire/release semantic or at least memory
> > fence ?
> > 

No No.
That's Cray trick. Memory dependancies are the same problem as register
one. But creating none coherent stream, a lot of optimising could be
done (7 load&store unit :)).

> > > But it didn't work any more for floating point unit. NAN, infinite
> > > must be implemented. Those execption came at the end of the
> > > pipeline of the unit. We could not hide latency any more. Each
> > > instruction must wait the complete end of the previous one. It
> > > will be so slow !
> > 
> > could not FPU store these flags into output register (or some
> > attached flag of it) and trap when the value is attempted to be used
> > ?
> > 
>

That's not the semantic of trap : roll-back on the faulty instructions.

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