RetroSearch Browse

Sat Jul 25 13:09:57 CEST 2009 · https://mail.python.org/pipermail/python-dev/2009-July/090846.html

>> This may not be recognized so far, because there is no builtin
>> GC-enabled type that embeds a double.
>> But if you create such a type, then the double will be correctly
>> aligned in your object's structure, but then, when the object
>> gets allocated, it is misaligned, because the header size is not a
>> multiple of 8.
> 
> I'm not sure a double aligned on a 4-byte boundary is "misaligned" on a x86 CPU.

That's not really the point. The question is whether the double is
misaligned wrt. the compiler's ABI. The compiler (or the operating
system) specifies the alignment for all primitive types, and guarantees
that everything is properly aligned.

> Alignment is primarily important to avoid access violations on CPUs and
> datatypes which don't support arbitrary alignment, although it can also be
> useful for performance reasons.

Alignment may also have propagated into other aspects. For example, if
you have

  double foo;
  intptr_t bar = (intptr_t)&foo;

then it may be guaranteed (by the ABI) that bar&7 == 0. So we really
need to keep all promises wrt. alignment intact.

> In any case, you seem to be right on this particular point: the PyGC_Head union
> should probably contain a "double" alternative in addition to the "long double"
> (and perhaps even a "long long" one).

I agree.

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-July/090846.html below:

[Python-Dev] mingw32 and gc-header weirdness