[Info-vax] SAMBA really sloooow on OVMS Integrity. Any Ideas????

John Reagan johnrreagan at earthlink.net
Wed Aug 18 15:54:18 EDT 2010


"Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message 
news:ebqdndZbSPxxrPHRnZ2dnUVZ_umdnZ2d at giganews.com...

> Usually, alignment errors have to be forced or something like that.  The 
> compilers will align everything properly unless the programmer 
> deliberately creates a data structure with non-aligned components. There 
> may, occasionally, be good reason to do something like this but I can't 
> think of one and I think best practice is to avoid it like the plague!

Incorrect.  Even if you pack a C struct real tight, the compiler knows that 
the fields are poorly aligned and will not generate instructions that will 
cause an alignment fault.  We'll pick it apart a byte at a time, mask, AND, 
shift, OR, etc.  Same is true for Pascal's PACKED RECORD, COBOL's default of 
unaligned, BASIC's unaligning in structs, C's nomember-alignment, etc.  You 
should never get an alignment fault in these cases (there was a recent [ie, 
a few years old] bug in COBOL that would result in alignment faults when the 
compiler should have known - the frontend lied to GEM - COBOL V5.9 fixed 
that if I remember correctly).

If you align your structures, you can get better performance by trading the 
5-7 instructions to get the poorly aligned field vs 1 instruction to get the 
well aligned field.   Plus the well aligned field doesn't have the chance to 
span across a cache boundary.  The poorly aligned field might.

In general, the two ways to get alignment faults are through pointer 
dereference and parameter access (which underneath the hood is just another 
form of pointer dereference).

As a quick example, write one routine that declares a pointer to an integer. 
malloc() yourself some memory.  Assign the result of memory+3 into the 
pointer to int.  Pass that pointer to int to another routine (or store it 
away somewhere for future use).  In that second routine, dereference that 
pointer to int.  The compiler will assume that the pointed-at integer is on 
an integer boundary.  However, you cheated and shoved "memory+3" into that 
pointer.

John 





More information about the Info-vax mailing list