> > z = shift[5] ? (y >> shift[4:0]) : (y << shift[4:0])
>
> These are good for REG << SHIFT. But, do we care about REG << REG? If
> we did, which I suspect we don't, we could use
>
> wire is_small_neg = &{shift[31:5]};
> wire is_small_pos = ! |{shift[31:5]};
>
> always ...
> ...
> z <= is_small_neg? (y >> -shift[5:0])
>
> : is_small_pos? (y << shift[4:0])
> : {31{y[31] & x[31]}};
>
> The would reduce the negation to 5 bits.
It's normal for funny things to happen if you try to do a wide shift[1]. We
don't have to do anything sensible for shift counts >= 32. We are free to
either ignore the high bits, or use them to encode additional information.
For code generation purposes it doesn't matter whether a right shift is a
signed value, or an unsigned value with high bits set. Both only require a
single instruction. ie:
lshiftright: # reg1, reg2
or tmp, reg2, #0x20
shl result, reg1, tmp
is no worse than
lshiftright: # reg1, reg2
sub tmp, #0, reg2
shl result, reg1, tmp
The advantage of the former is we can use additional bits to encode other
types of shifts if they are required (eg. arithmetic shifts or rotates).
ashiftright: #reg1, reg2
or tmp, reg2, #0x60
shl result, reg1, tmp
Paul
[1] x86 ignores all but the low 5 bits, ARM ignores all but the low 8 bits,
and some cores use the whole value.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)