[Python-Dev] Alignment assumptions

[David Abrahams]

----- Original Message -----
From: "Tim Peters" <tim.one@comcast.net>

> > Include/objimpl.h:275: double dummy;  /* force worst-case alignment */
>
> One branch of a union, forces enough padding in the gc header so that
> whatever follows the gc header is "aligned enough".  This is sufficient
for
> all core gc types, but may not be sufficient for user-defined gc types.
I'm
> happy enough to view it as a restriction on what user-defined gc'able
types
> can contain.

As I read the code, it affects all types (doesn't this header begin every
object, regardless of its GC flags?) and I think that's a very unhappy
circumstance for your numeric community. Remember, the type that raised the
alarm here was just a long double.

> > At first glance, there appear to be different assumptions at work
> > here about what constitutes maximal alignment on any given platform.
>
> Only the objimpl.h trick might benefit from maximal alignment.

I'm not actually after maximal alignment; I look for a
minimally-sized/aligned type whose alignment is a multiple of the target
type's alignment. In any case, I was just using the assumption that double
was maximally aligned since I was linking with Python code and the EDG
front-end was too slow to handle the metaprogram -- I figured that if the
assumption was good enough for Python and my clients were depending on it
anyway, it was good enough for my code (not!).

> If you ever compile on a KSR machine, you'll discover there's no std C
type
> that captures maximal alignment.

I was aware that this was a theoretical possibility, but not that it was a
practical one. What's KSR?

> You'd have to guess it's an extension type
> named "_subpage".  I'm not sure that even C++ template metaprogramming
could
> manage that bit of channeling <wink>

Nope; we can only look through a list of likely candidates to try to find a
match. We're hoping to address this for the next standard -- I'm pushing for
allowing non-POD types in unions, leaving construction/destruction up to the
user.

> (FYI, _subpage required 128-byte
> alignment).

I guess that strictly speaking, requiring maximal alignment wouldn't be
appropriate for objimpl ;-)

> Stupid trick:  If you can compute this at run time, do malloc(1) a few
> times, count the number of trailing 0 bits in the returned addresses, and
> take the minimum.  Since malloc has to return memory "suitably aligned so
> that it may be assigned to a pointer to any type of object and then used
to
> access such an object or an array of such objects", you'd soon discover
you
> always got at least 7 trailing zero bits back from KSR malloc(), and
> presumably at least 4 under Tru64.

Sounds like a good candidate for your autoconf script.
Seriously, though, I think it would be reasonable to stick to aligning the
standard builtin types, in which can you can do the test without calling
malloc, FWIW.

> there's-the-standard-and-then-there's-real-life<wink>-ly y'rs  - tim

in-theory-theory-and-practice-are-the-same-and-to-hell-with-what-happens-in-
practice-ly y'rs

-Dave