word alignment for structures in UNIX

[Ed Benyukhis]

In article <5020 at quiche.cs.mcgill.ca>, mikey at quiche.cs.mcgill.ca (Michael GALLOP) writes:
> Please note: The poster is only a grad student at Mcgill and does not reflect 
> the undergrad education :- ) 

At least he is asking relevant questions.  You, on the other hand, do not have manners
and enough education as well.  Grow up!!!!  And while you are at it, read some
computer and compiler architecture literature.

> 
> 
> Well Alain. There are several different factors. First off when dealing with 
> any two machines, your request will likely return different values. 
> 
> 
> One of the reasons-perhaps the main one- is the different architectures in 
> the CPUs of the machines. From what I remember 80X86 swaps the bytes around 
> from the way the SPARC deals with them 

Endianess has absolutely nothing to do with the data alignment rules.  You have to
understand the difference between the alignment restrictions of a machine and the alignment
policy of the compiler.  Contrary to what you are saying, some machines, like INTEL
80x86 and VAX, have NO alignment restrictions.  Data objects of any type can be referenced
at any address boundary without causing a machine exception.  Even on such machines, 
however, data access may be more efficient at certain alignment boundaries.
For each type, the alignment policy of the compiler determines what addresses the compiler
will use in placing data objects declared to be of that type.  The compiler implementor's
freedom in choosing an alignment policy is limited by the alignment restrictions of the
hardware.  The alignment policy may be stricter than the machine's alignment restrictions
for reasons of efficient access.  A machine may be able, for instance, to access a long
integer beginning at any byte boundary, yet it may access longs more quickly if their
first byte's address is a multiple of 4 .......
In general, the alignment policy must at least be as strict as the hardware's alignment
restrictions.  However, different COMPILERS for the SAME machine may have different
alignment policies.  Each compiler chooses an alignment policy based on the trade off
of space efficiency vs. run-time efficiency.

> 
> 
> More importantly is the difference in word size. An 80386 is a 32 bit machine 
> -in some modes. In fact all of these are 32 bit machines. However the 
> register addressing is different on each one. The Sparc uses circular 
> addressing, whereas the i386 uses a form of virtual addressing. 
> 
> Further, an important factor is the overhead of your C compiler, your OS. 
> These _MIGHT_ ( probably won't) affect the result returned.... 
> This, coupled with the different ways that each OS allocates memory 
> will result in your observations. 
> 

This is off the wall. The processor's programming model and its addressing
modes have no bearing on the alignment, other than ones described above.  I don't
think you have enough knowledge to contribute any more to this discussion, let alone,
"reflect and undergraduate education".  You do, however, behave like an undergraduate.

> 
> Why, though are you asking ? You can't magic number a (Not can't- shouldn't) 
> malloc. So you should 
> if ( ( malloc ( sizeof ( foo ) ) ==NULL ) 
> or whatever is needed. 
> 
> As for patching it in the kernel, I couldn't possibly see why, or how, you'd 
> do that. By hard wiring a value like that in the kernel, you cause havoc in 
> the rest of the OS. Especially in a 386. If you were to do that on a 386 in 
> 386 protected mode, or, worse in virtual 8086 mode, the page frame would 
> cause a memory fault- I should know, I spent many hours chasing my mistake 
> on that one I tried to align with a magic number :- ( -and dump the machine. 


regards,


Edward Benyukhis
Motorola, CID (Cellular Infrastructure Division) of RTSG
(708)632-4658