On Tue, 16 Mar 2010 06:50:30 -0800, H.J. Lu <hjl.to...@gmail.com> wrote: > 2010/3/8 Pawe=C5=82 Sikora <pl...@agmk.net>: > > hi, > > > > during development a cross platform appliacation on x86 workstation > > i've enabled an alignemnt checking [1] to catch possible erroneous > > code before it appears on client's sparc/arm cpu with sigbus ;) > > > > it works pretty fine and catches alignment violations but Jakub Jelinek > > had told me (on glibc bugzilla) that gcc on x86 can still dereference > > an unaligned pointer (except for vector insns). > > i suppose it means that gcc can emit e.g. movl for access a short int > > (or maybe others scenarios) in some cases and violates cpu alignment rule= > s. > > > > so, is it possible to instruct gcc-x86 to always use suitable loads/stores > > like on sparc/arm? > > > > [1] "AC" bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing) > > > > I am interested in an -mstrict-alignment option for x86.
Me too. One use I have in mind is in emulators for ISAs that require alignment checks. Setting the AC bit would allow the emulator to replace explicit alignment checks with the x86 host's alignment checks, which could speed up emulation and reduce code volume (for JITs). However, this relies on gcc and glibc to not generate too many misaligned accesses. The glibc bit can be worked around (use a replacement libc or offload libc accesses to a sibling thread that runs with AC=0), but gcc does need to be instructed to not generate code with misaligned accesses. Another use is in implementations of dynamically-typed languages like Lisp. You can choose a tagging scheme so that CAR and CDR become simple loads with appropriate offsets. If the tagged pointer happens to not be a CONS, you'll get an alignment exception. /Mikael
