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

[John Wallace]

On Nov 30, 9:12 pm, JF Mezei <jfmezei.spam... at vaxination.ca> 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 ?
>
> >> 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 un 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.
>
> BTW, does the X86-64 have similar performance handicap when trying to
> fetch an integer from unaligned memory location ?


(overlapped with JR's post) [apologies if duplicate, first allegedly
failed]

Much of this is to do with modern memory subsystem implementation. A
naturally aligned access will not cross a cache line boundary. An
access which isn't known at compile time to be naturally aligned *may*
cross a cache line boundary at run time, and depending on the hardware
and software, that may be quite undesirable in performance terms.
Think of the implications in a high end SMP system which has to keep
its per-CPU caches consistent somehow - that was a large part of the
target IA64 market, and today is effectively the only IA64 market
(outside of VMS). Other chip architectures can't be so choosy. But
even in a single CPU system there are implications if page boundaries
and memory management considerations and the like come into the
picture.

AMD64 hardware and software must make this kind of thing relatively
transparent to the application programmer, because it must provide
compatibility with legacy code and data from the x86 world. For the
reason mentioned above, it cannot make it entirely transparent to the
system designer and OS programmer.

On the dark side, the mechanism used in Visual Studio to tell a
(64bit) compiler that data may be unaligned is __declspec(align
(number)) described in more depth at:
http://msdn.microsoft.com/en-us/library/83ythb65.aspx
Or perhaps, for IA64 only, it's __unaligned
http://msdn.microsoft.com/en-us/library/ms177389.aspx

Not sure about the gcc equivalent (where I work mostly uses the dark
side at the moment). Not even sure whether gcc is relevant to IA64
anyway (at one time a couple of years back, icc was recommended rather
than gcc, don't know about current state of play).

Although the usual response to discussions like this is "design your
code to align your data appropriately", there are times when this
isn't a low cost (or even a possible) option - when compatibility with
existing file or network data formats from other apps is required, for
example.

Hth.