[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention]
- To: f-cpu@seul.org
- Subject: Re: Re: [f-cpu] reg. rotation [Was: New suggestion about call convention]
- From: whygee@club-internet.fr
- Date: Thu, 28 Nov 2002 12:46:31 CET
- Delivered-To: archiver@seul.org
- Delivered-To: f-cpu-outgoing@seul.org
- Delivered-To: f-cpu@seul.org
- Delivery-Date: Thu, 28 Nov 2002 06:46:32 -0500
- Reply-To: f-cpu@seul.org
- Sender: owner-f-cpu@seul.org
hi,
>De: cedric
>
>hi,
>
>> 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 ?
absolutely.
I will need another, better reason than "it is possible"
to be convinced that it is really necessary.
> 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,
so this will require to discard the condition field.
do you remember that the "move" instructions are conditional ?
> if we implement all the instruction specified in the manual.
i don't understand why there should be a relation with the other
instructions.
> I don't see where will be the overhead in hardware,
it's not orthogonal with the move instructions.
> but I think it can be usefull for a lot of code.
> So why not ?
Why make something that will become complex
in the next generations of F-CPU ?
> (A more precise answer will be appreciate ;-)
try to think about the decoding+issue logic
of a more complex implementation of F-CPU,
for example one that executes 2 (or more)
instructions per cycle.
> Cedric
YG
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/