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

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



hi again,

>De: Antoine
>> > cedric wrote:
>> > >dmove syntax will be more like this (if it exist) :
>> > >	dmove r2, r1
>> > >the behaviour will be :
>> > >	r1 = r2
>> > >	r1^1 = r2^1
>> > >But I don't know if it will possible to implement it, but it's a good idea
>> > > I think.
>> 
>> > i don't think so (TM)
>> 
>> Are you sure ? I was thinking that we currently need a mecanism to read r1 and 
>> r1^1 and to write r2 and r2^2 at the same cycle, if we implement all the 
>> instruction specified in the manual. I don't see where will be the overhead 
>> in hardware, but I think it can be usefull for a lot of code. So why not ? (A 
>> more precise answer will be appreciate ;-)
>
>I think the answer is : CISC (tm) ?

yup.

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.

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

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

YG

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