[Qemu-devel] tcg shift ops and magnitudes larger than register size

[Qemu-devel] tcg shift ops and magnitudes larger than register size

[Mike Frysinger]

are there any rules with the tcg sar/shl/shr ops and their magnitudes
?  such as "magnitudes cannot be larger than the register size" ?

i have a 32bit register with the value of 0x1230002 and when i attempt
to do a sari with a value >=32, it gives me 0x918001 (a single shift
right has been done).  i would have expected the value to be 0 (as
that is what my architecture does).
-mike

Re: [Qemu-devel] tcg shift ops and magnitudes larger than register size

[Edgar E. Iglesias]

On Wed, Jan 12, 2011 at 08:13:45PM -0500, Mike Frysinger wrote:
> are there any rules with the tcg sar/shl/shr ops and their magnitudes
> ?  such as "magnitudes cannot be larger than the register size" ?

Yes, the result is undefined in those cases.
 
> i have a 32bit register with the value of 0x1230002 and when i attempt
> to do a sari with a value >=32, it gives me 0x918001 (a single shift
> right has been done).  i would have expected the value to be 0 (as
> that is what my architecture does).

You need to handle it in the translator. CRIS has similar semantics
as your arch. See target-cris/translate.c:t_gen_lsl() for one way
of doing it. There might be better ways though.

Cheers

Re: [Qemu-devel] tcg shift ops and magnitudes larger than register size

[Stuart Brady]

On Thu, Jan 13, 2011 at 09:56:35AM +0100, Edgar E. Iglesias wrote:
> On Wed, Jan 12, 2011 at 08:13:45PM -0500, Mike Frysinger wrote:
> > are there any rules with the tcg sar/shl/shr ops and their magnitudes
> > ?  such as "magnitudes cannot be larger than the register size" ?
> 
> Yes, the result is undefined in those cases.

The result is also undefined if the magnitude is *equal* to the width of
the variable.

> You need to handle it in the translator. CRIS has similar semantics
> as your arch. See target-cris/translate.c:t_gen_lsl() for one way
> of doing it. There might be better ways though.

How widely used would a set of optional shift ops be, where the magnitude
may be equal to (or exceed?) the width?

Are there other helpers or op sequences that are commonly shared between
targets that would be candidates for splitting out into common code?

I know that a proliferation of ops is to be avoided -- the not, neg,
andc, orc, eqv, nand and nor ops have been useful though, despite not
being strictly essential, and the same could be said for the ext*s, ext*z
and bswap ops.

One of nice side-benefits of moving to TCG was that simple arithmetic ops
and loads/stores worked the same way on all targets.  Targets using
different orderings for dest / source parameters was not really fun when
switching constantly between SPARC, MIPS and x86 targets. :-/

Cheers,
-- 
Stuart Brady

Re: [Qemu-devel] tcg shift ops and magnitudes larger than register size

[Edgar E. Iglesias]

On Fri, Jan 14, 2011 at 11:26:21PM +0000, Stuart Brady wrote:
> On Thu, Jan 13, 2011 at 09:56:35AM +0100, Edgar E. Iglesias wrote:
> > On Wed, Jan 12, 2011 at 08:13:45PM -0500, Mike Frysinger wrote:
> > > are there any rules with the tcg sar/shl/shr ops and their magnitudes
> > > ?  such as "magnitudes cannot be larger than the register size" ?
> > 
> > Yes, the result is undefined in those cases.
> 
> The result is also undefined if the magnitude is *equal* to the width of
> the variable.
> 
> > You need to handle it in the translator. CRIS has similar semantics
> > as your arch. See target-cris/translate.c:t_gen_lsl() for one way
> > of doing it. There might be better ways though.
> 
> How widely used would a set of optional shift ops be, where the magnitude
> may be equal to (or exceed?) the width?

My guess is that they wouldn't be used very much. But they might deserve
a helper call that emits a good sequence of tcg calls to do the job.


> Are there other helpers or op sequences that are commonly shared between
> targets that would be candidates for splitting out into common code?

I'm sure there are. You just have to find them :)


> I know that a proliferation of ops is to be avoided -- the not, neg,
> andc, orc, eqv, nand and nor ops have been useful though, despite not
> being strictly essential, and the same could be said for the ext*s, ext*z
> and bswap ops.

There are many more that aren't "strictly essential". IMO, adding helpers
that emit frequently used sequences of tcg calls is mostly good.

Adding tcg ops that get exposed to the middle and backend is a different
matter.

Cheers