[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
safe.
This
> /* 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?