🚀 go-pugleaf

Kent Paul Dolan writes:

>If the goal is to share structures in a shared memory
>architecture, between two vendor's compilers, or two generations
>of one vendor's compilers, then none of the questions of
>endedness, bit ordering, efficient bit path width for fetches and
>stores will vary, nor need they be considered when laying out a
>standard for structure packing. Those problems exist
>_independently_ of any compiler, they are at the hardware level,

My understanding was, for instance, that it would be quite resonable
for one C or C++ compiler to implement signed bit fields, and another,
unsigned bitfields.  A similar situation applies to the grouping
chunk size of bit fields.  A choice of processor may suggest
certain sizes, but it by no means pins these things down precisely.
Jim correctly identifies these as compiler issues, not hardware
ones.

>and so a shared memory system among processors which disagree on
>such questions would very likely not be programmable in a compiled
>language in any case, and so would be either assembly programmed
>or, better, never built.

Correcting for your mistake in attributing these characteristics
to hardware when in fact they are compiler issues, your argument
in analogy would say that there is no point trying to share memory
structures between programs written with two different compilers.
Such a practice clearly has things to watch out for, but is 
frequently done. A similar sentence would apply to heterogeneous
multi-processors.

>Kent, the man from xanth.

	Bob Atkinson
	Microsoft