public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Reza Roboubi <reza@parvan.net>
Cc: Nicholas Sherlock <n.sherlock@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: short pointers (32 bit) in 64 bit apps
Date: Thu, 20 May 2010 03:16:00 -0000	[thread overview]
Message-ID: <mcr8w7f46hv.fsf@dhcp-172-17-9-151.mtv.corp.google.com> (raw)
In-Reply-To: <4BF421E0.9080009@parvan.net> (Reza Roboubi's message of "Wed\, 19 May 2010 10\:37\:36 -0700")

Reza Roboubi <reza@parvan.net> writes:

> And that gets your ALU's doing a lot of unneeded additions and
> subtractions, every time you access such pointers.

I don't see how you can possibly avoid ALU operations given your
design goals (i.e., permitting the pointers to exist in memory areas
other than the low 4GB).  You are just asking for a way to make the
compiler generate them automatically.

Heck, even if you don't like C++, you can do it yourself with macros.

struct s
{
  uint32_t ps; /* Pseudo-pointer to next struct in list.  */
  ...
};

#define GET_SPS(p) \
  ((struct s *) ((p)->ps | ((uintptr_t) (p) & 0xffffffff00000000ULL)))
#ifdef NDEBUG
#define SET_SPS(p, q) \
  ((p)->ps = (uint32_t) ((uintptr_t) q & 0xffffffff))
#else
#define SET_SPS(p, q) \
  (assert (((uintptr_t) (p) & 0xffffffff00000000ULL)
           == (uintptr_t) (q) & 0xffffffff00000000ULL),
   (p)->ps = (uint32_t) ((uintptr_t) (q) & 0xffffffff))
#endif

For extra credit use statement expressions to avoid multiple
evaluation of the macro arguments.

Ian

  parent reply	other threads:[~2010-05-20  3:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-17  9:51 Reza Roboubi
2010-05-18 14:45 ` Ian Lance Taylor
2010-05-19  5:58   ` Reza Roboubi
2010-05-19  8:27     ` Ian Lance Taylor
2010-05-19  8:55     ` Nicholas Sherlock
2010-05-19  9:24       ` Reza Roboubi
2010-05-19  9:46         ` Nicholas Sherlock
2010-05-19 18:34           ` Reza Roboubi
2010-05-19 21:24             ` Clemens Eisserer
2010-05-19 21:29               ` phi benard
2010-05-24 21:52                 ` Clemens Eisserer
2010-05-20  3:16             ` Ian Lance Taylor [this message]
2010-05-20 11:36               ` Nicholas Sherlock
2010-05-19  9:50         ` Andrew Haley
2010-05-19 19:08           ` Reza Roboubi
2010-05-20  2:29             ` John S. Fine

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=mcr8w7f46hv.fsf@dhcp-172-17-9-151.mtv.corp.google.com \
    --to=iant@google.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=n.sherlock@gmail.com \
    --cc=reza@parvan.net \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).