On Dec 2, 2008, at 10:03 AM, Michael Schwingen wrote:
Rick Altherr wrote:I'm also not entirely sure that a structure must always be aligned. I'm aware that some architectures will trap if an unaligned access isencountered, but the OS should catch the trap and handle the unalignedaccess correctly.No. AFAIK, C requires pointers to be aligned, and for good reasons - there are plattforms where unaligned accesses are simply not possible, and many OS's on those platforms *do not* emulate such accesses but simply terminate the offending process.This may sound strange for people who are used to X86 programming only, but portable code should avoid such constructs and not rely on the OS toemulate misaligned accesses. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Ironically, my day job has been exclusively on non-x86 platforms for years and only recently started with x86.
Pointers to data types should be aligned such that the data type is naturally aligned. That would mean that a 16-bit type should be 16- bit aligned. The question was related to structures. Since they are not a native data type, I wasn't sure that they required word alignment. I'll dig up my copy of the C standard and check.
In practice, most malloc() implementations return word-alignment at a minimum. This command queue allocation does not do any alignment today. So, the first item allocated in a command queue page will be malloc() aligned, but subsequent allocations are not guaranteed to be.
A few approaches can be taken to resolve this. One is to pad the allocations to a word-sized quantity. Another is to align the start of an allocation but not adjust the size used. Yet another is to have separate aligned and unaligned allocators. Yet another is to allow the required alignment to be specified.
To keep with malloc() semantics, guaranteeing that the allocations are at least word aligned is probably a good idea. That allows the pointer to be used for any types (except vector types) and requires minimal change in the code base. Padding the allocation size is arguably smaller in terms of code, but if that route is used, a detailed comment should proceed it explaining why the size is being padded. It should also be done as a modification of the used member of the page structure rather than as part of the requested size. That way it is clear that the size of the object allocated isn't changed, but that padding was added to force alignment.
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
