On Thu, Jan 23, 2014 at 03:26:45PM -0500, Jeff King wrote: > Looking over the format, I think the only thing preventing 4-byte > alignment is the 1-byte XOR-offset and 1-byte flags field for each > bitmap. If we ever have a v2, we could pad the sum of those out to 4 > bytes. Is 4-byte alignment enough? We do treat the actual data as 64-bit > integers. I wonder if that would have problems on Sparc64, for example.
Yes, it will. SPARC requires all loads be naturally aligned (4-byte to an address that's a multiple of 4, 8-byte to a multiple of 8, and so on). In general, architectures that do not support unaligned access require natural alignment for all quantities. Also, even on architectures where the kernel can fix these alignment issues up, the cost of doing so is a two context switches (in and out of the kernel), servicing the trap, two loads, some shifts and rotates, and a kernel message, so many people disable alignment fixups. I know it made things extremely slow on Alpha. ARM is even more fun since if you don't take the trap, it loads the data rotated, so the load happens, it just silently returns the wrong data. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
