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

Re: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention]

> 1) the "double move" is highly implementation dependent.
>    Nobody would have thought about it in another kind
>    of core. This means that if FC1 ever exists, either it
>    will have to drop the instruction, or the structure will
>    have to be adapted to be able to perform _one_ instruction.

Hum, I don't understand your problem. It exist instruction (like bitrev, mux, 
...), that need to read 2 paired registers and it exist some other 
instructions (like addsub, divmod, ...) that need to write 2 paired 
registers. So where is the cost ?

In fact the difference with move is really few, and we have still the flags 
room and the 3th operand free, if you want we have the same behaviour has 
move but with 2 paired registers.

> 2) you can split the "double move" into 2 simple instructions.
>    There are a lot of scheduling issues with this :
>       - first the destination will have to be paired.
>         it is probable that in certain (annoyingly
>         useful) situations, it is not possible.

That's not the problem, we have scheduler for this and they work well with 
this type of problem.

>       - the 2 sources are not likely to be ready/available
>         at the same clock cycle. This means that a MOVE
>         of one data can be easily blocked by another operand
>         that is not ready.

Same problem for bitrevi and mux, but for add, sub and other.

> Clearly the intent is to increase coding density
> at the cost of scheduling and flexibility.

In fact not, it increase the possibility of the scheduling to provide smaller 
and more efficient code and if you absolutely want to move only one register 
or not paired register you still have move instruction.

The idea is interesting, because in a lot of case parameter need to be moved 
from parameter register to other register. I want really to know where it 
cost in hardware, I think it's in the decoder, but I don't see where, because 
all is already present.


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