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


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