[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues in ia64

From: Marius Vollmer
Subject: Re: Issues in ia64
Date: 02 Jul 2002 21:01:25 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Thien-Thi Nguyen <address@hidden> writes:

> alignment for 64 bit machines and such introduces to the specification
> an MBZ field, let's call it machine-alignment-immediate-slack.

There are two kinds of minimum alignment involved: the one needed for
our tag system to work, and the one needed by the machine.

We only need 8-byte alignment for the tag system, even when scm_t_cell
is larger than 8 byte.  On machines with 64 bit pointers, where
scm_t_cell is 16 byte, we _could_ make use of the additional bit
afforded by aligning scm_t_cell:s on 16-byte boundaries, but we don't
need to.  Given that we want to support 32-bit machines in the
foreseeable future, it is probably easier to let the extra bit go to
waste than to use two different tagging schemes on 32-bit and 64-bit
platforms.  Thus, for our tagging scheme, we don't need to align cells
on 16 byte boundaries on 64-bit machines.

The alignment needed by the machine is a different issue, we need to
guarantee it no matter what.  The machine alignment is guaranteed by
malloc, and thus also by scm_gc_malloc, etc.  Since we are using the
memeory returned by malloc only as arrays of scm_t_bits and thus only
use offsets that are (in bytes) a whole multiple of
sizeof(scm_t_bits), we are not violating the alignment when creating
the strange 'struct' layout.

Or, with numbers: on a 32-bit platform the tag alignment is 8, the
machine alignment is at most 4, which gives a total alignment of 8.
On 64-bit platforms, the tag alignment is still 8, and the machine
alignment is at most 8, which gives again a total of 8.  So we are


>   /* Adjust it even further so it's aligned on an eight-byte boundary.  */
>   p = (scm_t_bits *) (((scm_t_bits) p + 7) & ~7);

is only there the satisfy the alignment for the tag system, which is 8
bytes, regardless of pointer size.

Therefore, I don't see the point of your patch.  Did I get this wrong?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]