🚀 go-pugleaf

[Context omitted due to size; please review last referenced article]

Without going to the trouble to filter through and analyze that
list step by step, you have enormously complicated a question by
introducing many non-pertinent items.

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,
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.

If the goal is to share structures from an offline store across
many generations of a vendor's compiler, then again either the
hardware bit, byte and word access strategies are constant, and
that level of detail need not be considered, or one is forced to
pay the major headache of doing a bit by bit translation of a data
base when changing machine architectures. (I've taken a 36 bit
machine's 50,000 reels of mag tape data to a 32 bit machine; I'm
intimately familiar with the problems involved here; I wrote the
record reformatter.) Again, this is a problem that exists
independently of compilers at all, and so that level of detail is
not needed.

If the goal is to share structures across a communications
network, then either smart translators rearrange the "endedness"
or bit ordering of the data, or not, depending on the
correspondence between the architectures at each end, but when the
structures are handed to the non-translator software, the standard
at the appropriate level of detail still provides unchanged access
to the data, since it's natural units are still packed the same
way, albeit they may be reordered appropriate to the architecture
within (not among) themselves. Again, the question of which end of
the word arrives first across the communications channel is
independent of any compiler, and the almost certainly assembly
language translator does not see the data in the same structured
way that a C++ object is viewed.

The same thing happens if the data structures are to be shared
between two architectures via an offline medium.  While one level
of translation to take into account architectural differences may
be needed, at the level of packing those differences are not so
important; when trying to decide whether to pack two byte entities
on two or four byte boundaries, it matters not a whit whether they
have their most significant bits/bytes first or last.

On the question of pointers, it is well known that pointers do not
port offline, so structures containing pointers will _always_ be
revised to contain counts or other ways of indicating how a linked
structure should be rebuilt.  Again, this translation must happen
independently of even whether the ultimate consumer of the data was
compiled or assembled, and is independent of the question of structure
layout standards.  For internal consumption, (finessing for the
moment the question of near-far architectural bogosities) the shape of
a pointer is constant, and so the question again does not cause any
difficulties with defining a structure layout standard.

The question of whether to pack bits across various byte
boundaries does need to be considered, but so long as the software
at the C++ programmmer's level sees the results as consecutive
bits, as mandated by the standard, it need not be terribly
interesting how the hardware sees them. I'm not sure I'm
comfortable with allowing an arithmetic shift as a way to access
those bits; I think that needs to be buried; but I'm quite
comfortable with saying "pack bitfield m after bitfield n in the
third int16; now assign this value to bitfield m" and having the
compiler cause the architecture to do what I say. What I gain by
knowing this is the ability to move the larger (byte, int16,
int32) unit, in which I have packed a set of bitfields, as an
entity, for efficiency, and knowing for certain which bitfields I
just moved, and that it was efficient in fact and not a
gather-scatter operation going on where I cannot see it happening
except in an assembly dump of my code.

I apologize if this is not expressed terribly clearly; I am not
tremendously expert in these areas.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>