Re: [f-cpu] Trying to clean up the ROP2 mess

[Yann Guidon <whygee@f-cpu.org>]

Michael Riepe wrote:

> On Thu, Jan 09, 2003 at 01:59:28AM +0100, Yann Guidon wrote:
>  
> > hello,
> >
> > Michael Riepe wrote:
> >
> >    
> > > Subject says it all. We need to make this more regular/orthogonal, and
> > > more consistent with the way other instructions work. In particular,
> > > we should provide operation variants that
> > >
> > >   - work for 8/16/32/64 bit chunks
> > >   - mask off the high bits / work on full registers
> > >   - use direct/and/or mode
> > > did you read one of my mails of yesterday about this subject ?
> > >      
> Yes.
>
>  
> > did you look at FORMAT.txt in the source snapshot ?
> >    
> Yes.
>
> > why is MUX not included ? (it is performed by the ROP2 unit
> > and uses a subset of the functions)
> >    
> Oh, I forgot that. But there will also be two variants:
>
>    mux.size    r3, r2, r1  // truncates / zero-extends
>    smux.size   r3, r2, r1  // operates on full word (size ignored)
>  
well, i think that the s- prefix on the logic operations looks confusing.
why not try the following : when no size prefix is given, it operates on 
the whole register ?

this would avoid the silly questions like : what does the "sand" 
instruction do ? :-)
(cf : my "sel" and "poivre" instructions...)

> [...]
>  
> > well, we don't converge on these last details but the encoding i 
> > proposed is able to do that
> > (except that there are 2 size fields, one for the writeback size and one 
> > for the combine chunk size).
> >    
> That's one of the problems. Since you re-used the SIMD flag for the
> additional size flags,
??? did i miss something ?

> there is no longer a way to specify a register-wide
> operation (remember that registers may be much wider than 64 bits).
> Besides that, the second size flag makes the encoding inconsistent
> with the majority of instructions (one goal is to keep the decoder
> simple!). For the same reason, I dropped the secondary size flags from
> the original `widen' instruction.
>  
This second size flag is necessary and since it's not going to be larger 
than 64 bits/chunks,
it's not as complex as the main size flags. So it can probably become 
inconsistent,
but it remains consistent with itself (00=8 bits (default), 01= 16 bits, 
10= 32 bits, 11=64 bits)
This is not the same problem with wide, IIRC...

> > > I will implement this encoding scheme in the next release of my
> > > assembler/disassembler/emulator trio.
> > you're going to have too much fun : you're insane :-)
> >    
> Did you try to install my fctools package? ;)
hell, i don't have any decently running linux box ....
shame on me ...

YG

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