Re: Portable dumper ideas
>>>> "OG" == Olivier Galibert
<galibert(a)pobox.com> writes:
OG> On Wed, Feb 16, 2000 at 03:10:26AM -0800, Martin Buchholz wrote:
> I had trouble understanding the alignment code, especially
> align_table. Ideas:
>
> Use ALIGNOF maybe?
OG> #ifndef ALIGNOF
OG> # if defined (__GNUC__) && (__GNUC__ >= 2)
OG> # define ALIGNOF(x) __alignof__ (x)
OG> # else
OG> # define ALIGNOF(x) sizeof (x)
OG> # endif
OG> #endif
OG> Nope, won't do. I don't want to align conses on a 12 bytes boundary
OG> when 4 bytes is enough.
In practice, all objects to be dumped can use ALIGNOF this:
union
{
struct { Lisp_Object obj; } obj;
struct { void *p; } p;
};
unless they contain a double, in which case ALIGNOF this:
union
{
struct { Lisp_Object obj; } obj;
struct { void *p; } p;
struct { double d; } d;
};
will do.
> The maximum alignment required should be perhaps (from opaque.h)
>
> typedef union
> {
> struct { Lisp_Object obj; } obj;
> struct { void *p; } p;
> struct { double d; } d;
> } max_align_t;
>
>
> We could move max_align_t to lisp.h, and have
>
> size_t max_alignment = ALIGNOF (max_align_t);
OG> Maybe. I know 256 as a max is overkill, but it doesn't cost us
OG> anything, since we enumerate objects in reverse alignment order and
OG> we're only using powers of two.
OG> Yes, I know, that's perverted code, but it does a perverted thing.
The only thing I know it costs us currently is the head-scratching I
do whenever I look at that code.
If it doesn't cost us anything to use oversized alignments, why not
just always use ALIGNOF (max_align_t) to align everything we dump?
Are we likely to actually dump anything that is going to have 1-byte
alignment? We might be able to do this for some opaque's, but since
the dumping code doesn't know how the opaques will be used, we can't.
And opaques have memory returned from malloc(), so it will also be
max_align_t-aligned.
Martin