Keith said:
I've already expressed my opinion of this behavior (that it's a bug,
even if it's not a violation of the standard).
This isn't a SPARC only thing, in addition to Windows/MIPS, the
Microsoft compiler doc state this:
"Itanium: An application must explicitly call SetErrorMode with
SEM_NOALIGNMENTFAULTEXCEPT to have the system automatically fix
alignment faults. The default setting is for the system to make
alignment faults visible to an application." [1]
people working with HPC, might also be interested in knowing:
"In addition, if the Alignment Mask bit is set in Control Register 0
(CR0), an unaligned memory reference may cause an alignment check
exception. For more information on this topic, see the AMD64
Architecture Programmer’s Manual, Volume 2, order# 24593." [2]
Furthermore, it's a rather bad idea on most RISC architectures, it's a
fault. The system may, or may not mask the fault. Typically, unaligned
access will *at least* give a performance penalty, as it do on x86.
Windows, typically mask such alignment faults on the x86 by default,
except for [1]. However, this don't always need to be the case, for
e.g. MIPS, the MSDN doc state an explicit Win32 call was needed:
SetErrorMode(GetErrorMode() | SEM_NOALIGNMENTFAULTEXCEPT);
to make Windows automatically do the fix-up on alignment faults.
MIPS is a rather exotic case, but programmers shouldn't expect that
x64 will be so forgiving to alignment faults, as x86 has been. Don't
be surprised if the penalty become significant bigger in this case.
In my opinion, if a compiler is going to support structure members
that don't have the alignment for the member's type, it's the
compiler's job to generate code that will access that member in a way
that (apart from performance and code size) is indistinguishable from
accessing an aligned member.
Well, I don't think most system programmers agrees with you, since this
leads to code bloat, hiding of translation details and do hurt performance.
C is close to a WYSIWYG language, which helps in generating compact,
predictable code, the language add little obfuscation for system
developers. The spirit of C, is to trust the programmer and not stop
him/her from doing exactly what asked.
If I instruct the compiler to do explicit alignment, that is what it
should provide. I can understand if application programmers don't care
much if the compiler generate some fix-up code to handle alignment
issues, but others don't want it.
On an x86, as I understand it, the compiler can just generate code to
access the member normally, and it's handled in hardware.
Well, I am not that interested in checking out old x86 manuals on this.
Have my hand full with the x64 manuals.
However, after a quick peek in
/usr/src/linux-headers-x.x.xx-xx/arch/i386/kernel/traps.c
I do find
void __init trap_init(void)
{
...
set_trap_gate(17,&alignment_check);
...
}
which show that the Linux kernel, at least handle x86 bus issues via
trap gate 17. Perhaps this kernel function address page alignment faults
only, or other alignment faults as well. I don't know.
However, most x86 HW exceptions due to alignment, appears to be masked
away on Windows and Linux kernel, what other kernels do here, is
difficult to tell without checking it. However, I can't remember seeing
such alignment exception code in the FreeDOS kernel...
On a SPARC, the compiler can, for example, do the equivalent of
memcpy() to copy the unaligned member to or from an aligned temporary.
Agreed
Or maybe it can access it directly and clean up after the fault. The
language, or the extension, doesn't need to specify *how* this is
done, just that it needs to be done properly.
No. A C compiler can't generally be granted access to ring 0 of the
kernel, the kernel is the boss of which signals are masked and which
signals are forwarded. The compiler run in user space, and should not
(due to security reasons) have access to higher privilege levels. The
operating system might (like Windows do via the SetErrorMode API)
provide a system call to mask alignment faults, or it might not.
Blindly trying to access the member as if it were aligned, when the
compiler itself chose to misalign it (in response to a pack pragma) is
just dumb.
The cases I have been interested in some particular alignment of struct
members, has either been in network code or in cases where I wanted to
store the struct on disk.
The obvious C solution, is then to do the conversion yourself, e.g.
struct T { ... } object;
unsigned char buffer[sizeof object];
and convert each struct member explicit into 'buffer'. This is a fully
portable method among C implementations and different architectures.
I've worked in languages that have the equivalent of packed
structures, and this is what they do.
And in such languages, packing comes with a price.. e.g. what could have
been done via a single load, now require two loads. In a HPC cluster,
you don't want such "packing" on a memory bound programs.
[1]
http://msdn2.microsoft.com/en-us/library/ms680621.aspx
[2] "Software Optimization Guide for AMD Family 10h Processors"
