linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Gabriel Paubert <paubert@iram.es>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Steve Munroe <sjmunroe@us.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Anton Blanchard <anton@samba.org>
Subject: Re: Saving to 32 bits of GPRs in signal context
Date: Tue, 29 May 2007 15:04:00 +0200	[thread overview]
Message-ID: <08b3997ab86a819c63b5cb0afcdc0c9e@kernel.crashing.org> (raw)
In-Reply-To: <20070529092658.GA32228@iram.es>

> But it also makes me wonder about a few things:
> - do you use the standard 32 bit ABI, in which case the caller of 
> libraries
>   does not care and the libraries can be put in the standard places,

The compiler should either a) use full 64-bit only for
"volatile" (call-clobbered) registers, or b) save and
restore other 64-bit mode registers around calls.  I don't
remember if powerpc-linux-gcc does a) or b), if either.

> or are
>   there cases where the ability to pass 64 bit values in a single
>   register would improve performance to the point that it is worth
>   having an incompatible library (where to put it and how to name it)?

That would be a third ABI.  Is it worth that?

> - how can an application know that it can use 64 bit registers and call
>   the optimized routines?

Just call them and trap the SEGV ;-)  You can check the
aux vector of course, or ask glibc -- but the SEGV way
is the only really portable way.  Strange world :-)

> Finally, I've not seen a compiler (well, GCC, but I don't have 4.2 or
> 4.3 installed yet) that allows you to tell the compiler to use 32 bit
> addresses but assume that integer registers are 64 bit wide.

This feature was developed in the 3.3 timeframe IIRC.  The
flags to use are -m32 -mpowerpc64 .

> As long
> as such an option does not exist, the usefulness of this feature is
> somewhat limited. In other words, GCC for now has support for ILP32 and
> LP64 modes, but it would be better to also have support for IP32L64.

ILP32LL64.  The C "mode" stays the same, only the generated
machine insns are changed.

> Adding the IP32L64 mode des not seem to be such a huge project
> (comparable to many Google SoC ones, but it's too late for 2007),

GCC (and many 3rd party apps/libs) *really* like pointers and
longs to have the same size.

> the problem is taht if it is started now, I don't think it will hit
> an official GCC release before 2009 at the earliest.

It has been there for a long time now ;-)

> Only the implicit flags calculations, cmp has both 32 and 64 bit
> versions, so it's not _that_ bad. However multiprecision arithmetic 
> will
> have to be done in 32 bit mode

You actually want to do MP calc in 64-bit mode -- multiplies
are four times faster!  (64x64 vs. 32x32).

> because the carry setting[1] is linked with the mode

True enough, but you never really need the CA reg anyway.

> (well I seem to remember a variant of the architecture
> which had 32 and 64 bit variants for generating the flags, but it was a
> long time ago. I've not seen support for this hybrid monster in gcc's 
> md
> file and I don't know whether it ever saw the light).

Book E 64.  You want to forget; well I want to anyway.

> Have you considered the case of a mixed (IP32L64) mode calling a pure
> 32 bit library (or a user provided callback). The high part of R13-R31
> will also be clobbered. Therefore the caller has to save and restore
> all registers that are live around the call, which results in
> significant code bloat and needs compiler support.

I believe the compiler supports this.  The code bloat you
think is there just doesn't exist; it takes a lot more code
to do the actual ops on a pair of 32-bit regs than it takes
to do a bit of 64-bit save/restore work.


Segher

  parent reply	other threads:[~2007-05-29 13:04 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29  7:24 Saving to 32 bits of GPRs in signal context Benjamin Herrenschmidt
2007-05-29  7:52 ` Dan Malek
2007-05-29  8:05   ` Benjamin Herrenschmidt
2007-05-29  9:26     ` Gabriel Paubert
2007-05-29  9:44       ` Benjamin Herrenschmidt
2007-05-29 13:12         ` Segher Boessenkool
2007-05-29 14:00           ` Steve Munroe
2007-05-29 14:08             ` Ulrich Weigand
2007-05-29 14:17               ` Kumar Gala
2007-05-29 14:38                 ` Segher Boessenkool
2007-05-29 19:04                   ` Becky Bruce
2007-05-30 10:04                     ` Christoph Hellwig
2007-05-30 12:13                       ` Kumar Gala
2007-05-30 12:30                     ` Segher Boessenkool
2007-05-29 14:31               ` Segher Boessenkool
2007-05-29 14:51               ` Steve Munroe
2007-05-29 21:44                 ` Benjamin Herrenschmidt
2007-05-29 23:16                   ` Steve Munroe
2007-05-29 23:19                     ` Benjamin Herrenschmidt
2007-05-30  7:34                     ` Hiroyuki Machida
2007-05-30 11:40                   ` Segher Boessenkool
2007-05-30 11:48                     ` Benjamin Herrenschmidt
2007-05-30  3:37                 ` Paul Mackerras
2007-05-30  5:32                   ` Kumar Gala
2007-05-30 11:44                     ` Benjamin Herrenschmidt
2007-05-30 12:15                       ` Kumar Gala
2007-05-30 12:48                         ` Hiroyuki Machida
2007-05-30 12:58                           ` Benjamin Herrenschmidt
2007-05-30 18:09                             ` Steve Munroe
2007-05-30 21:02                       ` Gabriel Paubert
2007-05-30 21:41                         ` Steve Munroe
2007-05-30 12:01                     ` Segher Boessenkool
2007-05-30 11:59                   ` Segher Boessenkool
2007-05-30 12:01                     ` Benjamin Herrenschmidt
2007-05-30 12:07                       ` Segher Boessenkool
2007-05-30 12:09                         ` Benjamin Herrenschmidt
2007-05-30 12:36                           ` Segher Boessenkool
2007-05-29 14:28             ` Segher Boessenkool
2007-05-29 21:37             ` Benjamin Herrenschmidt
2007-05-29 21:38               ` Benjamin Herrenschmidt
2007-05-29 13:04       ` Segher Boessenkool [this message]
2007-05-29 14:28         ` Arnd Bergmann
2007-05-29 14:43           ` Segher Boessenkool
2007-05-29 15:54             ` Geert Uytterhoeven
2007-05-29 18:48             ` Arnd Bergmann
2007-05-29 21:27         ` Benjamin Herrenschmidt
2007-05-29 21:45           ` Felix Domke
2007-05-30 11:23             ` Benjamin Herrenschmidt
2007-05-30 11:52               ` Felix Domke
2007-05-30 13:14                 ` Segher Boessenkool
2007-05-30 11:54             ` Segher Boessenkool
2007-05-30 12:07               ` Felix Domke
2007-05-31  5:39                 ` Benjamin Herrenschmidt
2007-05-29 13:10     ` Kumar Gala
2007-05-29 21:32       ` Benjamin Herrenschmidt
2007-05-29 23:46         ` Olof Johansson
2007-05-30  0:43           ` Kumar Gala
2007-05-30  2:54             ` Steve Munroe
2007-05-30  5:31               ` Kumar Gala
2007-05-30 19:47                 ` Steve Munroe
2007-05-30 20:52                   ` Olof Johansson
2007-05-30 21:33                     ` Steve Munroe
2007-05-29 13:53 ` Ulrich Weigand

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=08b3997ab86a819c63b5cb0afcdc0c9e@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=anton@samba.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paubert@iram.es \
    --cc=paulus@samba.org \
    --cc=sjmunroe@us.ibm.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 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).