unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Alignment of Lisp_Subr
Date: Wed, 12 Nov 2003 18:30:13 -0500	[thread overview]
Message-ID: <20031112233013.GB27000@fencepost> (raw)
In-Reply-To: <jwv8ymld1jm.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>

On Wed, Nov 12, 2003 at 11:22:33AM -0500, Stefan Monnier wrote:
> - Structures of type Lisp_Subr are statically allocated and are not
>   guaranteed to be aligned on a multiple of 8.  I currently solve this
>   by adding __attributes__ ((__aligned__ (8))), but this only works for GCC
>   AFAIK.  The only alternative I can think of is to add a padding field
>   to Lisp_Subr and when its address is not a multiple of 8, memmove it
>   by a few bytes (I think `defsubr' is the only place where we refer
>   to these statically allocated Sfoo variables).
>   Any comment on which approach is preferable ?

I think the compiler will force the structure to be aligned to the strictest
alignment of any component, so if you stick an field with 8-byte-alignment in
there _somewhere_, the compiler should do everything for you.  It should even
work to put the `forcing field' in as a member of a union with another field,
and simply never use the forcing field.  On many platforms, `double' could be
used as the type of the forcing-field, but I'm not sure how universal this
is.

Given that subrs are not the most space critical object though, it seems
simplest to just use __attributes__ when compiling with gcc (#ifdef
__GNUC__), and add the padding field when compiling with another compiler.

> - malloc does not guarantee on all systems that the returned value
>   will be a multiple of 8 (or does it?).

It guarantees `most strict' alignment, which on many platforms is 8 bytes
(because of doubles), and I think many malloc implementations are
conservative and assume 8 bytes anyway.  However I don't think you can assume
this though; a quick google shows plenty of people complaining about exactly
this issue (they expected 8-byte alignment, and got less; common culprits
seem to be MS and SCO mallocs... :-)

I guess in the common case where emacs uses its builtin malloc, or glibc's,
you'll have #defines to tell you though...

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

  reply	other threads:[~2003-11-12 23:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-12 16:22 Alignment of Lisp_Subr Stefan Monnier
2003-11-12 23:30 ` Miles Bader [this message]
2003-11-13 16:18   ` Stephen J. Turnbull
2003-11-14  5:23     ` Gaute B Strokkenes
2003-11-14 11:28       ` Stephen J. Turnbull
2003-11-16 10:25         ` Gaute B Strokkenes
2003-11-13  2:40 ` Richard Stallman

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=20031112233013.GB27000@fencepost \
    --to=miles@gnu.org \
    --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).