Unaligned memory access

2
votes

I am playing around with memory addresses in C and wondering about this topic named unaligned memory access.

I am currently on a x86 Intel with Linux kernel, but ask the topic in the spirit of arch and OS agnosticism – though the following is rather Linux and HW specific:

When I read/write a simple type from/to an unaligned address I get no fault. No messages in logs or anything. I have also tried:

perf top -e alignment-faults
# And with PID
perf top -p NNN -e alignment-faults

but no hits.

Turning on alignment checking by:

__asm__("pushf\norl $0x40000,(%esp)\npopf");

gives the "wanted" result:

Bus error (core dumped)

(but still no messages in perf.)

My question is how this is handled by the hardware + OS and what is optimal. My thoughts and questions are all over the place, but I'll try to phrase some concrete points:

  1. Does the CPU have alignment checking on by default, but the kernel detects that off is supported and instructs it to do not check?
  2. As the kernel, at least I have experienced this on other HW, can get oops due to some driver trying to access unaligned memory: does the kernel run in alignment check-mode? Or is it perhaps only certain parts of the code that does?
  3. As access of unaligned memory require more resources; is it a good idea to enable alignment checking, as by for example above assembly line, in a test-phase for software? Would this also make it more portable?

I have a lot of more questions around this, but leave it at this for now.

1
cmemoryassemblykernel
A big reason why alignment is even a topic is because some architectures check and one/some dont. the ones that do may or may not have an enable/disable. Also the check is done in hardware such that the memory/fetch cycle has a fault. – old_timer
Working from memory…Intel (CISC) chips can manage unaligned writes — at a speed cost, I believe. RISC chips in general (SPARC specifically, I believe others too) will generate a bus error when requested to access misaligned data (a 2-byte quantity on an odd memory address; a 4-byte quantity on an address that is not a multiple of 4 bytes), etc. Some chips (DEC Alpha) generate a kernel trap and deal with the misaligned access in the kernel — which is dreadfully slow. There was a command, uam, to control whether programs crashed on an unaligned access to memory or the kernel trap occurs. – Jonathan Leffler
For your first question, I don't think there is an on/off mode, it is more like whether the OS or compiler can handle in software the problems raised by unaligned memory access. If it can be handled then I see no reason why it would be turned off for some code and not enabled for some other. Hope you find the following two links useful, msdn.microsoft.com/en-us/library/aa290049%28v=vs.71%29.aspx lwn.net/Articles/260832 – AquaAsh
Thanks folks. This is slowly sinking in, and I'd say the cumulated information trough answers and comments are good so I'll accept (and read on in manuals etc. ;) ). – Zimzalabim
@AquaAsh: My thought was that in a kernel one would turn this off if it increase performance in the CPU. My initial thought was that if it has support for it, (alignment fixing), a request (by the CPU) would first be issued. If MMU don't reply – try fix. – But that trough how this is implemented on HW level it could have performance penalty even on valid requests. A second point would be, (for cross support), to implement this for code that is production critical. Believe I have read that some CPU's can reply with bad alignment, but then the data would be compromised. (Thus "let HW handle it") – Zimzalabim

1 Answers

2
votes

Just try to give a partial answer.

Does the CPU have alignment checking on by default, but the kernel detects that off is supported and instructs it to do not check?

It depends on the arch and even on same arch it might be that some instructions on unaligned memory can be handled by HW while others can not.

As the kernel, at least I have experienced this on other HW, can get oops due to some driver trying to access unaligned memory: does the kernel run in alignment check-mode? Or is it perhaps only certain parts of the code that does?

Unaligned memory access no supported by HW would cause a trap and kernel has handler for the trap/exception. I've been working on ppc and such exception would be handled based on the instruction (gotten from the PC); some instructions are taken care of and the program would resume; some others might cause the program to terminate as kernel cannot handle it. One such example is the the stwcx instruction which is used to implement compare-and-swap logic.

As access of unaligned memory require more resources; is it a good idea to enable alignment checking, as by for example above assembly line, in a test-phase for software? Would this also make it more portable?

In practice it might not be a good idea if you have a lot of legacy code in a large project..... but it should be good for new code.