Re: [f-cpu] Instruction census

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

On Tue, 14 Jan 2003 22:18:59 +0100 (CET)
devik <devik@cdi.cz> wrote:

> > > yep ... gcc can't prefetch and "cache" data in registers too
> > > early because of read-write ordering rules which can't be
> > > resolved by aliasing analysis. It is why IA-64 has ld.a
> > > instruction. There if flag which tells gcc to use "possibly
> >
> > Could you explain what does ld.a ? What is the read-write ordering
> > rules?
> 
> ld.a is so called advanced load of IA-64 which loads data
> from address and places the address into TLB like structure
> (with 64 entries for Itanium IIRC).
> Later completion load checks whether the item is still present,
> if yes, latter load in NOP. If no, the latter load reloads
> data.
> In C if you write *a = b; c = *d; you have to ensure RAW
> ordering of "a" store and "d" read because you don't often
> don't know whether they can alias (interestingly
> *a = b, c = *d; don't need to enforce it - it is paralel
> expression).
> IA64 can do advanced load before store and then do check
> load after store - it is often nop.
> If CPU would store to the same address it would remove
> store address from the disambiguation memory thus forces
> latter check-load to reload.
> The same effect has full disambiguation memory (old pointer
> dropped) or other CPU dirtying cache line of pointer.
> 
> IA64 has also speculative load ld.s - its only difference is
> that it doesn't trap - if it would like trap it stores the condition
> in flag associated to the destination register.
> When such value would be used it would then really trap.
> Completion load can check the flag and jump to special stub
> code to handle it.
> It allows you to load *a in expression if (a) b = *a; without
> change of side effect.
> 

What is the différence between prefetch of x86 ? Is it the same
difference between preload and prefetch ? Does not an L1 do the job ? 

> > >
> > > well, mac is not yet supported - we have generaly problems
> > > with ^1 register addressing.
> > >
> > What kind of problem ?
> 
> MR explained me that MAC doesn't have that problem. But
> MUX has - there is no clean way to tell gcc that insn
> places result to register r^1 ...
> It can be done for divrem because it uses expander. But
> MUX will gave to be solved by 3-2 split point of gcc only
> because it consists of 3 RTL insns.
> 

i particulary hate the r^1 adressing :) Is that easier to define paired
register ? It through aways some flexibility but could you say to gcc to
consider register as extended one (writing the result in a double sized
register like x86 mess). For a 2r2w, the write port will be R2-R3, R3-R2
is also true but could be avoided in a first time ?

> > > use vector modes explicitly but it works oonly with
> > > programs whose knows how to use them. gcc will not
> > > emit them itself.
> > >
> > It's even impossible to detect "obvious" scheme ? (like
> > C[i]=A[i]*B[i] or A+=V1[i]*V2[i] ?)
> 
> no. It requires vectorizer which is not present in gcc yet.
> But loop optimizer is planed to be rewritten and vectorizer
> will be probably added too.
> 

:( it seems so easy !

> > > By the way: If we implement load-linked/store-conditional, we may
> > > also implement speculative loads á la Itanium. The mechanism is
> > > the same: keep an eye on the memory location and set a flag when
> > > it's been stored into after the load.  When the `completion load'
> > > finds the flag set, it re-fetches the data.  We could handle that
> > > kind of things in the LSU.
> >
> > (Be carfull on itanium patent !)
> 
> which one ? so I know what things don't thing about at all .. :-(
>

arf. Itanium is a recent design so probably full of patent. All
"inovation" in Itanium design is certainly soon patented.

> BTW what is load-linked/store-conditional ?

I don't think so or by an other chip maker.

nicO

> 
> devik
> 
> *************************************************************
> 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/