18

Pardon me if you feel this has been answered numerous times, but I need answers to the following queries!

  1. Why data has to be aligned (on 2-byte / 4-byte / 8-byte boundaries)? Here my doubt is when the CPU has address lines Ax Ax-1 Ax-2 ... A2 A1 A0 then it is quite possible to address the memory locations sequentially. So why there is the need to align the data at specific boundaries?

  2. How to find the alignment requirements when I am compiling my code and generating the executable?

  3. If for e.g the data alignment is 4-byte boundary, does that mean each consecutive byte is located at modulo 4 offsets? My doubt is if data is 4-byte aligned does that mean that if a byte is at 1004 then the next byte is at 1008 (or at 1005)?

David Kay
  • 1,006
  • 10
  • 16
MS.
  • 881
  • 2
  • 9
  • 23

7 Answers7

17

CPUs are word oriented, not byte oriented. In a simple CPU, memory is generally configured to return one word (32bits, 64bits, etc) per address strobe, where the bottom two (or more) address lines are generally don't-care bits.

Intel CPUs can perform accesses on non-word boundries for many instructions, however there is a performance penalty as internally the CPU performs two memory accesses and a math operation to load one word. If you are doing byte reads, no alignment applies.

Some CPUs (ARM, or Intel SSE instructions) require aligned memory and have undefined operation when doing unaligned accesses (or throw an exception). They save significant silicon space by not implementing the much more complicated load/store subsystem.

Alignment depends on the CPU word size (16, 32, 64bit) or in the case of SSE the SSE register size (128 bits).

For your last question, if you are loading a single data byte at a time there is no alignment restriction on most CPUs (some DSPs don't have byte level instructions, but its likely you won't run into one).

Yann Ramin
  • 32,895
  • 3
  • 59
  • 82
  • hi theatrus, here is my doubt again! why is it that the lower 2 address lines are eliminated? Coz with this setup I can only access data from addresses 0, 4, 8.. so on. So how do the Byte manipulations are taken care in such situation? You mentioned there is no alignment restriction for a single data byte, how this is achieved when the bottom 2 address lines are don't care? Thank you for your reply! – MS. Jun 12 '10 at 06:29
  • Mostly I am concerned about why the address lines are don't care when there may be byte manipulation intended in my code (and go all the way round about to do the same..)? – MS. Jun 12 '10 at 06:35
  • 4
    Intel CPUs have no performance penalty for unaligned access within a cache line. Aligning data is useful for avoiding cache-line splits, where some bytes are in one line and some are in another, but with all bytes in the same 64-byte line, like loading a DWORD from `[0x4000007]` or something, it's a single access to cache. (On old CPUs, SSE `movdqu` was slow even with aligned addresses, but on Nehalem and later there's only a penalty for crossing 64-byte boundaries and especially page boundaries. AMD's x86 CPUs have some effects at 32 byte boundaries, and maybe 16.) – Peter Cordes Sep 24 '18 at 04:42
  • 3
    See [Why is integer assignment on a naturally aligned variable atomic on x86?](https://stackoverflow.com/q/36624881): loads / stores that are naturally atomic are that way because the CPU does them as a single operation, and for cached accesses, tearing doesn't happen when cache lines are copied around. See also [Choice between aligned vs. unaligned x86 SIMD instructions](https://stackoverflow.com/q/52147378) for SSE/AVX unaligned. Aligning your data is usually a good thing, but your reasoning isn't quite right, and it's only critical on modern x86 for AVX512 (every vector is a full line). – Peter Cordes Sep 24 '18 at 04:47
7

Very little data "has" to be aligned. It's more that certain types of data may perform better or certain cpu operations require a certain data alignment.

First of all, let's say you're reading 4 bytes of data at a time. Let's also say that your CPU has a 32 bit data buss. Let's also say your data is stored at byte 2 in the system memory.

Now since you can load 4 bytes of data at once, it doesn't make too much sense to have your Address register to point to a single byte. By making your address register point to every 4 bytes you can manipulate 4 times the data. So in other words your CPU may only be able to read data starting at bytes 0, 4, 8, 12, 16, etc.

So here's the issue. If you want the data starting at byte 2 and you're reading 4 bytes, then half your data will be in address position 0 and the other half in position 1.

So basically you'd end up hitting the memory twice to read your one 4 byte data element. Some CPUs don't support this sort of operation (or force you to load and combine the two results manually).

Go here for more details: http://en.wikipedia.org/wiki/Data_structure_alignment

Timothy Baldridge
  • 10,455
  • 1
  • 44
  • 80
  • 7
    +1 for the link, but you should note that only some processors tolerate misaligned data. Intel does for IA32 and IA64 architecture, but not for Itanium. Your explanation is true only for processors that are tolerant for misaligned data such as IA32/IA64. Alpha AXP would generate a fault, and I think MIPS would as well. Some OSs would handle the misaligned data in the fault handler, but the performance penalty for that is huge. And if the OS doesn't handle it, the misaligned data doesn't work _at all_ for those systems. – John Knoeller Jun 11 '10 at 18:40
4

1.) Some architectures do not have this requirement at all, some encourage alignment (there is a speed penalty when accessing non-alignet data items), and some may enforce it strictly (misaligment causes a processor exception).
Many of todays popular architectures fall in the speed penalty category. The CPU designers had to make a trade between flexibility/performance and cost (silicon area/number of control signals required for bus cycles).

2.) What language, which architecture? Consult your compilers manual and/or the CPU architecture documentation.

3.) Again this is totally architecture dependent (some architectures may not permit access on byte-sized items at all, or have bus widths which are not even a multiple of 8 bits). So unless you are asking about a specific architecture you wont get any useful answers.

Durandal
  • 19,919
  • 4
  • 36
  • 70
2

In general, the one answer to all three of those questions is "it depends on your system". Some more details:

  1. Your memory system might not be byte-addressable. Besides that, you might incur a performance penalty to have your processor access unaligned data. Some processors (like older ARM chips, for example) just can't do it at all.

  2. Read the manual for your processor and whatever ABI specification your code is being generated for,

  3. Usually when people refer to data being at a certain alignment, it refers only to the first byte. So if the ABI spec said "data structure X must be 4-byte aligned", it means that X should be placed in memory at an address that's divisible by 4. Nothing is implied by that statment about the size or internal layout of structure X.

    As far as your particular example goes, if the data is 4-byte aligned starting at address 1004, the next byte will be at 1005.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
2

Its completely depends on the CPU you are using!

Some architectures deal only in 32 (or 36!) bit words and you need special instructions to load singel characters or haalf words.

Some cpus (notably PowerPC and other IBM risc chips) dont care about alignments and will load integers from odd addresses.

For most modern architectures you need to align integers to word boundies and long integers to double word boundries. This simplifies the circutry for loading registers and speeds things up ever so slighly.

James Anderson
  • 27,109
  • 7
  • 50
  • 78
1

Data alignment is required by CPU for performance reason. Intel website give out the detail on how to align the data in the memory

Data Alignment when Migrating to 64-Bit Intel® Architecture

One of these is the alignment of data items – their location in memory in relation to addresses that are multiples of four, eight or 16 bytes. Under the 16-bit Intel architecture, data alignment had little effect on performance, and its use was entirely optional. Under IA-32, aligning data correctly can be an important optimization, although its use is still optional with a very few exceptions, where correct alignment is mandatory. The 64-bit environment, however, imposes more-stringent requirements on data items. Misaligned objects cause program exceptions. For an item to be aligned properly, it must fulfill the requirements imposed by 64-bit Intel architecture (discussed shortly), plus those of the linker used to build the application.

The fundamental rule of data alignment is that the safest (and most widely supported) approach relies on what Intel terms "the natural boundaries." Those are the ones that occur when you round up the size of a data item to the next largest size of two, four, eight or 16 bytes. For example, a 10-byte float should be aligned on a 16-byte address, whereas 64-bit integers should be aligned to an eight-byte address. Because this is a 64-bit architecture, pointer sizes are all eight bytes wide, and so they too should align on eight-byte boundaries.

It is recommended that all structures larger than 16 bytes align on 16-byte boundaries. In general, for the best performance, align data as follows:

  • Align 8-bit data at any address
  • Align 16-bit data to be contained within an aligned four-byte word
  • Align 32-bit data so that its base address is a multiple of four
  • Align 64-bit data so that its base address is a multiple of eight
  • Align 80-bit data so that its base address is a multiple of sixteen
  • Align 128-bit data so that its base address is a multiple of sixteen

A 64-byte or greater data structure or array should be aligned so that its base address is a multiple of 64. Sorting data in decreasing size order is one heuristic for assisting with natural alignment. As long as 16-byte boundaries (and cache lines) are never crossed, natural alignment is not strictly necessary, although it is an easy way to enforce adherence to general alignment recommendations.

Aligning data correctly within structures can cause data bloat (due to the padding necessary to place fields correctly), so where necessary and possible, it is useful to reorganize structures so that fields that require the widest alignment are first in the structure. More on solving this problem appears in the article "Preparing Code for the IA-64 Architecture (Code Clean)."

Shen liang
  • 1,385
  • 15
  • 15
  • Your quote mentions IA-64. That's Itanium, not x86-64. However, that advice does apply to current x86-64 CPUs. It's also what the x86-64 System V ABI chooses to do for alignment of primitive C types. (With `alignof(short) = 2` because there's no way to relax for the middle 2 bytes of a 4-byte chunk inside a struct.) – Peter Cordes Jul 23 '19 at 01:31
1

For Intel Architecture, Chapter 4 DATA TYPES of Intel 64 and IA-32 Architectures Software Developer’s Manual answers your question 1.

Jingguo Yao
  • 7,320
  • 6
  • 50
  • 63