From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: tags in the 3 lowest bits
Date: 20 Nov 2003 11:21:52 +0100 [thread overview]
Message-ID: <m3oev7qr0f.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <jwvr803skhy.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
> > The only reason I can see for this is that there is a small
> > performance penalty on XFASTINT with LSB -- but I'd prefer that
> > penalty rather than having to support two different methods.
>
> I doubt the performance penalty is an issue. After all, manipulating MSB
> is generally slightly more costly than LSB, so the performance impact might
> even be positive. But I expect it's a wash.
Once LSB is in place, I would like us to get rid of XFASTINT
all-together. It's a potential danger lurking to hit us.
>
> > Or are there systems which cannot use LSB?
>
> The LSB code needs pointers values that are multiples of 8.
> On some systems, malloc does not guarantee it. Probably we can use
> gmalloc.c for those systems, but we'll need to make sure that's an option
> and we'll need to figure out when that's nmecessary.
We could wrap malloc and free on such systems to force 8 byte alignment like
this (it's a little costly in memory, but no big deal):
char *malloc_wrap(size_t len)
{
char *p = malloc(len + 16);
char *p1 = p;
p = (char *)((unsigned)(p + 15) & ~0x7);
*(char **)(p - 8) = p1;
return p;
}
char free_wrap(char *p)
{
free(*(char **)(p - 8));
}
> Also, there might be
> systems that are word-addressed rather than byte-addressed. I don't know
> if such systems are still in use and whether Emacs runs on them, but if
> yes, we'll probably need to find some other way to deal with them,
> maybe keeping the old behavior.
>
> I also hope we can switch to LSB everywhere, but I don't think we can
> do that right now.
>
> I suggest to start with something like along the lines of
>
> #if defined GLIBC || defined GNU_MALLOC
> #define USE_LSB_TAG
> #endif
That's a good starting point, yes.
Or we could use the above trick like this:
#if !(defined GLIBC || defined GNU_MALLOC)
#define malloc malloc_wrap
#define free free_wrap
#endif
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2003-11-20 10:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-19 19:15 tags in the 3 lowest bits Stefan Monnier
2003-11-20 0:28 ` Kim F. Storm
2003-11-19 23:32 ` Miles Bader
2003-11-20 5:14 ` Stefan Monnier
2003-11-20 10:21 ` Kim F. Storm [this message]
2003-11-20 9:31 ` Miles Bader
2003-11-20 10:49 ` Kim F. Storm
2003-11-22 21:18 ` Richard Stallman
2003-11-20 14:52 ` Stefan Monnier
2003-11-21 15:32 ` Stefan Monnier
2003-11-22 0:31 ` Kim F. Storm
2003-11-21 23:56 ` David Kastrup
2003-11-22 1:45 ` Kim F. Storm
2003-11-24 0:08 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3oev7qr0f.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).