[Info-vax] Dave Cutler, Prism, DEC, Microsoft, etc.

Richard B. Gilbert rgilbert88 at comcast.net
Mon Nov 30 17:00:14 EST 2009


JF Mezei wrote:
> The Compiler guy was heard typing:
> 
>>> Remember that except for compiler bugs, alignment faults comes from the user
>>> lying to the compiler.
> 
> 
> Excuse me, but are there really circumstances where the programmer
> ("user" from Mr Reagan point of view) is lying to the compiler ?
> 
> if I have a 100 byte record, and bytes 7 though 10 inclusively contain
> an integer, and I do:
> 
> myint = (int *) &(buffer + 6) ; /* hopefully I have the syntax right*/
> 
> In what way am I lying ?  Does the compiler realise that this will be an
> unaligned access or will it be accusing me of lying ?
> 
> 
> Out of curiosity, why do some CPUs have so much trouble fetching 4 bytes
> from an unaligned location ? Is it the CPU and CPU architecture that is
> the problem, or the RAM memory subsystem that can't fetch 4 bytes
> starting at an uneven memory address ?
> 
Well VAX certainly did!  Alpha, IIRC was even more sensitive to 
alignment issues.  If you knew that, it was not difficult to satisfy the 
machines preferences.  The compilers took care of most of the work.

The VAX and Alpha architectures were by no means unique in having this 
requirement.  The IBM System/360 and System/370 machines also required 
proper boundary alignment.

Normally the compiler took care of alignment.  There were cases; e.g. 
data structures, where things could become unaligned.  The machine would 
   complain and then move the offending data to properly aligned storage.

It meant your program ran a little, or a lot, slower and with warning 
messages about the alignment faults.

>>> if you can't, tell the compiler
>>> what you did and we'll avoid the alignment fault.
> 
> In C, how can I tell a compiler that trying to move 4 bytes into an
> integer variable MAY cause an alignment fault ? With variable record
> structures for instance, the location of an integer may vary and
> sometimes be an uneven offset from start of buffer. But you won't
> know that at compile time since it would vary from record to record as
> you process a file for instance.
> 

So the machine grumps a little, fixes the alignment, and your program 
runs a little
or a lot slower!  Good programmers try keep things aligned or alignable 
and most succeed.

If you do a four byte move, there's no problem.  If you try to use 
longword instructions to move it, you will get an alignment fault, the 
fixup routine will be called and your program is a little slower than it 
needs to be.

Smart programmers will go to great lengths to make sure that data in 
records gets transferred to properly aligned storage.




More information about the Info-vax mailing list