From: Kyle Moffett <kyle@moffetthome.net>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Duncan Sands" <baldrick@free.fr>,
llvmdev@cs.uiuc.edu, "Ingo Molnar" <mingo@elte.hu>,
"Török Edwin" <edwintorok@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [LLVMdev] inline asm semantics: output constraint width smaller than input
Date: Wed, 28 Jan 2009 08:28:33 -0500 [thread overview]
Message-ID: <f73f7ab80901280528m6a4f123axbaff9ec284bebe32@mail.gmail.com> (raw)
In-Reply-To: <497FBB30.3020804@zytor.com>
On Tue, Jan 27, 2009 at 8:56 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Kyle Moffett wrote:
>> Actually, PPC64 boxes basically don't care... the usable GPRs are all
>> either 32-bit (for PPC32) or 64-bit (for PPC64), the <=32-bit
>> instructions are identical across both, they just
>> truncate/sign-extend/etc based on the lower 32-bits of the register.
>> Also, you would only do a right-shift if you were going all the way
>> out to memory as 64-bit and all the way back in as 32-bit... within a
>> single register it's kept coherent.
>
> Think about a 64-bit integer on ppc32. It will by necessity kept in two
> registers. On gcc I believe it will always be a consecutive pair of
> registers (AFAIK that's a hard-coded assumption in gcc, with the result that
> gcc has a nonstandard internal register numbering for x86 since the commonly
> used dx:ax pair is actually registers 2:0 in the hardware numbering.)
Even in the 64-bit-integer on 32-bit-CPU case, you still end up with
the lower 32-bits in a standard integer GPR, and it's trivial to just
ignore the "upper" register. You also would not need to do any kind
of bit-shift, so long as your inline assembly initializes both GPRs
and puts the halves of the result where they belong.
Cheers,
Kyle Moffett
next prev parent reply other threads:[~2009-01-28 13:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-23 17:57 Török Edwin
2009-01-23 18:17 ` Ingo Molnar
2009-01-23 18:21 ` H. Peter Anvin
2009-01-23 18:27 ` Török Edwin
2009-01-23 18:30 ` Ingo Molnar
2009-01-23 18:52 ` Török Edwin
2009-01-23 20:42 ` Török Edwin
2009-01-24 16:23 ` Török Edwin
2009-01-24 17:27 ` Ingo Molnar
2009-01-24 18:57 ` Török Edwin
2009-01-24 21:25 ` [LLVMdev] " Mike Stump
2009-01-24 19:23 ` Chris Lattner
2009-01-24 21:10 ` H. Peter Anvin
2009-01-27 19:42 ` Duncan Sands
2009-01-27 21:25 ` H. Peter Anvin
2009-01-28 1:45 ` Kyle Moffett
2009-01-28 1:56 ` H. Peter Anvin
2009-01-28 13:28 ` Kyle Moffett [this message]
2009-01-28 17:29 ` H. Peter Anvin
2009-01-28 19:27 ` Kyle Moffett
2009-01-28 20:59 ` H. Peter Anvin
2009-01-24 20:07 ` Andreas Schwab
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=f73f7ab80901280528m6a4f123axbaff9ec284bebe32@mail.gmail.com \
--to=kyle@moffetthome.net \
--cc=baldrick@free.fr \
--cc=edwintorok@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvmdev@cs.uiuc.edu \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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
Powered by JetHome