From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: jsrhbz@kanargh.force9.co.uk,
christoph.muellner@theobroma-systems.com, linux@roeck-us.net,
linux@rasmusvillemoes.dk, paulmck@linux.vnet.ibm.com,
tglx@linutronix.de, mingo@kernel.org, akpm@linux-foundation.org,
hpa@zytor.com, maxime.coquelin@st.com,
linux-kernel@vger.kernel.org, martink@posteo.de, tytso@mit.edu,
linux-tip-commits@vger.kernel.org
Subject: Re: [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions
Date: Mon, 19 Jan 2015 11:04:39 +0100 [thread overview]
Message-ID: <20150119100439.GN25256@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CA+55aFyc7TbnLBi3rcQDrtkwg9TgDnb5dAfupMGSbTKZC6Xd0g@mail.gmail.com>
On Mon, Jan 19, 2015 at 07:54:22AM +1200, Linus Torvalds wrote:
> Why?
>
> The 8- and 16- bit versions are the same as the 32-bit one. This seems
> pointless. If you want something where the sign is in bit 3, they all
> return the same value, just the return type differs, but that's really a
> *caller* thing, no?
Even for the 8bit ones? Since we have the *H and *L register we have
more 8 bit regs than we have 16/32 bit regs and it might just be worth
it.
Since these are inlines the whole calling convention which would clobber
the whole of eax can go away.
Now granted, this is all very tenuous at best. A more convincing
argument might be that of documentation; calling sign_extend32() on
something you know to be a byte might be less intuitive.
next prev parent reply other threads:[~2015-01-19 10:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 17:22 [PATCH v2] bitops.h: add sign_extend8(), 16 and 64 functions Martin Kepplinger
2015-01-12 17:28 ` [RFC] input: gtco: use bitops' sign_extend8 Martin Kepplinger
2015-01-12 17:28 ` [RFC] rtc: use sign_extend8 instead of manual conversion Martin Kepplinger
2015-01-12 17:28 ` [RFC] media: stb0899: use sign_extend8 instead of manual work Martin Kepplinger
2015-01-12 17:28 ` [RFC] hwmon: jc42: use bitops' sign_extend16 Martin Kepplinger
2015-01-12 19:53 ` Guenter Roeck
2015-01-12 19:48 ` [PATCH v2] bitops.h: add sign_extend8(), 16 and 64 functions Guenter Roeck
2015-01-14 16:56 ` [RFC PATCH 0/4] Example changes using proposed sign_extend functions Martin Kepplinger
2015-01-14 16:56 ` [PATCH 1/4] input: gtco: use bitops' sign_extend8 Martin Kepplinger
2015-01-14 16:56 ` [PATCH 2/4] rtc: use sign_extend8 instead of manual conversion Martin Kepplinger
2015-01-14 16:56 ` [PATCH 3/4] media: stb0899: use sign_extend8 instead of manual work Martin Kepplinger
2015-01-14 16:56 ` [PATCH 4/4] hwmon: jc42: use bitops' sign_extend16 Martin Kepplinger
2015-01-18 19:06 ` [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions tip-bot for Martin Kepplinger
[not found] ` <CA+55aFyc7TbnLBi3rcQDrtkwg9TgDnb5dAfupMGSbTKZC6Xd0g@mail.gmail.com>
2015-01-19 1:11 ` Guenter Roeck
2015-01-19 4:00 ` Linus Torvalds
2015-01-20 12:30 ` [PATCH v3 0/2] bitops.h: add sign_extend64() API and improve doc Martin Kepplinger
2015-01-20 12:30 ` [PATCH 1/2] bitops.h: improve documentation for sign_extend32() Martin Kepplinger
2015-01-20 12:30 ` [PATCH 2/2] bitops.h: Add sign_extend64() API Martin Kepplinger
2015-01-19 10:04 ` Peter Zijlstra [this message]
2015-01-21 20:22 ` [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions H. Peter Anvin
2015-02-05 7:17 ` Ingo Molnar
2015-02-05 14:11 ` Guenter Roeck
2015-02-12 11:11 ` Example use of sign_extend64() Martin Kepplinger
2015-02-12 11:11 ` [RFC][PATCH] arch: sh: use sign_extend64() for sign extension Martin Kepplinger
2015-02-05 16:39 ` [tip:core/types] bitops: Add sign_extend8(), 16 and 64 functions H. Peter Anvin
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=20150119100439.GN25256@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=christoph.muellner@theobroma-systems.com \
--cc=hpa@zytor.com \
--cc=jsrhbz@kanargh.force9.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@roeck-us.net \
--cc=martink@posteo.de \
--cc=maxime.coquelin@st.com \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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