From: Stuart Brady <sdb@zubnet.me.uk>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] tcg shift ops and magnitudes larger than register size
Date: Fri, 14 Jan 2011 23:26:21 +0000 [thread overview]
Message-ID: <20110114232621.GA5779@zubnet.me.uk> (raw)
In-Reply-To: <20110113085635.GA7296@edde.se.axis.com>
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
next prev parent reply other threads:[~2011-01-14 23:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-13 1:13 [Qemu-devel] tcg shift ops and magnitudes larger than register size Mike Frysinger
2011-01-13 8:56 ` Edgar E. Iglesias
2011-01-14 23:26 ` Stuart Brady [this message]
2011-01-15 21:00 ` Edgar E. Iglesias
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110114232621.GA5779@zubnet.me.uk \
--to=sdb@zubnet.me.uk \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).