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

Re: [f-cpu] Conditionnal Load and Store




<big snip>

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

Absolutely nothing, I mean no prefetch, no memory operation, ...

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

I think that most of us want to remove this instruction or change it a lot.
In fact we need a loadaddr in a absolute mode, so why not changing it's
definition to something more useful ?

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

Ok, I understand. Hum, I now understand your question about my conditionnal
loadaddr too. I don't know the cost of a conditionnal loadaddr in fact, but 
reducing memory bandwith is usefull, so not an easy decision.

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

Yes, and in fact some other instructions too. Like memory operation if we 
didn't want to explode memory bandwith.

Cedric

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