From: David Howells <dhowells@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: dhowells@redhat.com, Tony Breeds <tony@bakeyournoodle.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-next: triage for March 18, 2012
Date: Mon, 19 Mar 2012 19:41:44 +0000 [thread overview]
Message-ID: <8010.1332186104@redhat.com> (raw)
In-Reply-To: <161084.1332177826@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> Umm.. it's not clear to *me* that it's intended to be a negative 16 bit? Or
> am I just missing context not present in the patch?
>
> (I have no idea if the rest of the patch is OK or not, but that comment
> didn't give me warm fuzzies....)
Sorry, I haven't explained it well.
The patch permits a 64-bit hosted assembler to represent a large 32-bit
unsigned integer (such as 0xfffffff1) as a negative integer where the
instruction being assembled has a signed immediate operand.
For instance, the ANDI instruction on FRV takes a small signed integer (10
bits IIRC) that it sign-extends to 32-bits before using - so to clear a single
low-order bit, I pass in, say, ~0x2 and the assembler represents this as a
negative value.
The problem was that in a 64-bit hosted assembler, the unsigned 32-bit integer
gets converted to an unsigned 64-bit integer - which doesn't then appear
negative (whereas in a 32-bit hosted assembler it does).
David
next prev parent reply other threads:[~2012-03-19 19:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-18 18:41 linux-next: triage for March 18, 2012 Paul Gortmaker
2012-03-18 18:41 ` Paul Gortmaker
2012-03-18 23:51 ` Tony Breeds
2012-03-19 14:51 ` Paul Gortmaker
2012-03-19 14:51 ` Paul Gortmaker
2012-03-27 23:59 ` Tony Breeds
2012-03-28 0:08 ` Paul Gortmaker
2012-03-19 15:03 ` David Howells
2012-03-19 15:21 ` David Howells
2012-03-19 17:23 ` Valdis.Kletnieks
2012-03-19 19:41 ` David Howells [this message]
2012-03-19 21:56 ` Valdis.Kletnieks
2012-03-19 22:20 ` Tony Breeds
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=8010.1332186104@redhat.com \
--to=dhowells@redhat.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=tony@bakeyournoodle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.