Re: [f-cpu] Conditionnal Load and Store

[Michael Riepe <michael@stud.uni-hannover.de>]

On Mon, Jul 29, 2002 at 06:14:27PM +0200, Cedric BAIL wrote:
> Quoting Michael Riepe <michael@stud.uni-hannover.de>:
> 
> > On Fri, Jul 26, 2002 at 03:18:15PM +0200, Cedric BAIL wrote:
> > > Why didn't we have conditionnal load and store. I mean somtehing like
> > > storez, storenz, loadz, loadnz, ... It can be really usefull and we can do
> > > with that all what we can do with predicate I think.
> 
> > Conditional load/store makes less sense than you may think. When an
> > address is loaded into a register, the prefetch cycle begins, whether
> > or not memory is actually accessed. Thus, there will be no increase in
> > memory bandwidth due to the use of conditional load/store.
> 
> Arf, I forgot prefetch... A conditional prefetch, is it possible ? ;-D
> 
> That not so stupid in fact. We have our strange cachemm instruction (I
> mean what did you think about : cachemmlcV, it's fun but have no sense...)
> So why not changing it, so that we have a conditionnal cachemm. In that case
> we need 2 more bits to define a register and 3 more for the test. And for
> loadaddr we have 11 unused bits, so we can have a conditionnal loadaddr too.
> I think that taking vacancy are not so good, I have crazy idea when I came back
> ;-)

What is a conditional loadaddr supposed to do if the condition is
false?

Cachemm is really strange (as well as serialize). I prefer not to
think about it ;)

> Now back to what you say, I was thinking that we make the test at start 
> (before sending the job to the LSU), but if I correctly understand, we send
> all and make the test at the same time, right ? That's strange.

If I remember correctly, the read operation of a conditional move will
be executed (because it is done at decode time) but the corresponding
write operation will never happen. This has nothing to do with the LSU,
however (the LSU is only used for memory load/store, not for moves).

> > The only positive effect ist that CL/S will avoid some jumps. That is,
> > in the rare case that you have code like
> >
> > 	if (condition) {
> > 		*pointer = expression;
> > 	}
> > 
> > with no preset and no else clause (or a volatile memory location),
> > and with a trivial expression (something that is already present in a
> > register, or can be computed with few additional instructions).  If
> > the computation of the expression becomes more complex, a jump is the
> > better choice. As soon as other statements precede or follow the assignment
> > (inside the if clause), it is a must anyway.
> 
> If think that a jump could be a good solution actually because we only issue
> one instruction per cycle, but what append if we issue more instructions ?
> I mean that of course we make reflexion for our ISA with big register, but
> we have the same reflexion with number of instructions per cycle.

That depends on the architecture. We can define `packets' of two,
four or even more instructions that are executed in parallel (that is,
Itanium-style EPIC), or a `stream' model that takes and executes as many
instructions as possible. In either case, jumps need special handling.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/