Path: utzoo!utgpu!watserv1!watmath!att!pacbell!indetech!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.std.c++ Subject: Re: Controlling structure layout (Re: Randomly ordered fields !?!?) Message-ID: <1990Sep12.083730.28345@zorch.SF-Bay.ORG> Date: 12 Sep 90 08:37:30 GMT References: <1990Sep4.163132@bert.llnl.gov> <1990Sep6.194543.7685@zorch.SF-Bay.ORG> <57316@microsoft.UUCP> Organization: SF Bay Public-Access Unix Lines: 85 [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.