unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: tags in the 3 lowest bits
Date: 20 Nov 2003 01:28:56 +0100	[thread overview]
Message-ID: <m3d6bn6fxz.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <jwvvfpgw4vv.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Here is my proposed patch which adds a new macro USE_LSB_TAG:
> if the macro is undefined, we behave as before, otherwise we
> use the lowest 3 bits of words for tags.

So the intention is to continue using MSB tags by default, and
only use LSB on those systems which really need it (eg. FreeBSD) ?

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.

Or are there systems which cannot use LSB?

 
> 
> Additionally to the above patch we will need to #define USE_LSB_TAG
> when appropriate: it seems that we'll have to put it into the
> [sm]/*.h files.
> 
> Any objection to my installing this patch ?
> 
> 
>         Stefan
> 
> 
> PS: The point of putting the tag in the LSB is that we can then use
>     the whole address space, which can be important on some systems
>     such as FreeBSD.
> 
> 
> Index: lread.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/lread.c,v
> retrieving revision 1.318
> diff -u -r1.318 lread.c
> --- lread.c	1 Sep 2003 15:45:56 -0000	1.318
> +++ lread.c	19 Nov 2003 19:09:00 -0000
> @@ -3407,6 +3407,16 @@
>       struct Lisp_Subr *sname;
>  {
>    Lisp_Object sym;
> +#ifdef USE_LSB_TAG
> +  /* Make sure the object has multiple-of-8 alignment.  */
> +  if (XTYPE (sname) != 0)

Clever :-)

> +    {
> +      struct Lisp_Subr *old_sname = sname;
> +      sname = (struct Lisp_Subr *) (4 + (char*) sname);
> +      memmove (sname, old_sname, sizeof (*sname) - 4);

I suggest using sizeof(sname->padding) rather than constant 4 here.

Or even better, use the actual "mis-offset", as this will work even
if we increase GCTYPEBITS later (also see below):

        ((1 << GCTYPEBITS) - (int)XTYPE (sname))



> @@ -752,6 +772,13 @@
>      char *symbol_name;
>      char *prompt;
>      char *doc;
> +#ifdef USE_LSB_TAG
> +    /* Lisp_Subrs are statically allocated, so we cannot rely on malloc
> +       giving us a multiple-of-8 alignment.  Instead, we assume that we
> +       get a multiple-of-4 alignment, and we memmove the object by 4 bytes
> +       if needed.  The memmove is in lread.c:defsubr.  */
> +    char padding[4];

Suppose we later increase GCTYPEBITS, this is more correct:

        char padding[(1 << GCTYPEBITS) - 4];


> +#endif
>    };
>  
>  \f
> @@ -1150,6 +1177,13 @@
>      unsigned gcmarkbit : 1;
>      int spacer : 15;
>      union Lisp_Misc *chain;
> +#ifdef USE_LSB_TAG
> +    /* Try to make sure that sizeof(Lisp_Misc) is a multiple of 8.
> +       This assumes that Lisp_Marker is the largest of the alternatives and
> +       that Lisp_Intfwd has the same size as Lisp_Free without padding.  */
> +    char padding[8 * ((sizeof (struct Lisp_Marker) - 1) / 8 + 1)
> +		 - sizeof (struct Lisp_Intfwd)];

I would prefer if this was also expressed in terms of GCTYPEBITS.

> +	      && offset < (STRING_BLOCK_SIZE * sizeof b->strings[0])

Why not offset < sizeof b->strings ?

> +	      && offset < (SYMBOL_BLOCK_SIZE * sizeof b->symbols[0])

Why not offset < sizeof b->symbols ?

> +	      && offset < (MARKER_BLOCK_SIZE * sizeof b->markers[0])

Ditto

> +#ifdef USE_LSB_TAG
> +  /* Ensure a minimum of 3 bits for tags. */
> +  size_t alignment = max (8, sizeof (EMACS_INT));

I suggest:

  /* Ensure a minimum of GCTYPEBITS bits for tags. */
  size_t alignment = max ((1 << GCTYPEBITS), sizeof (EMACS_INT));

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

  reply	other threads:[~2003-11-20  0:28 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 [this message]
2003-11-19 23:32   ` Miles Bader
2003-11-20  5:14   ` Stefan Monnier
2003-11-20 10:21     ` Kim F. Storm
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=m3d6bn6fxz.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).