Re: unaligned load/store

On 12/22/2024 2:01 AM, Thomas Koenig wrote:

MitchAlsup1 <mitchalsup@aol.com> schrieb:

On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:

 

Any competent programmer will ALIGN his data to the extend possible
there is no reason to penalize {Compiler, assembler, linker, ld.so,...}
just because you want to take 5 days out of design.

 These days, the competence of many programmers can be called into
question :-)
 ABIs, however, generally require natural alignment for types, so
the point is somehwat moot, at least where user code is concerned.
Consider
 typedef struct
{
   unsigned char a;
   unsigned long b;
} mytype;
 unsigned long add (mytype *x)
{
   return x->a + x->b;
}
 which gets translated into
          ldub    r2,[r1]
         ldd     r1,[r1,8]
         add     r1,r1,r2
         ret
 so the cost for the tool chain is already spent (or is spent
again and again if people use structs like the above).  I think
the VAX was the last major architecture which specified unaligned
struct access.
 

On Sat, 21 Dec 2024 23:22:35 +0000, Jonathan Thornburg wrote:

 

So yes, allowing unaligned access does help "dusty deck" Fortran code...
but it comes at a significant cost.

 Fortran compilers, even on machines which allow misalignment, use
ABIs which specify alignment for COMMON blocks, in violation of
the Fortran standard.  They usually have a flag for when the
user actually needs to have no padding.
 Code which which would not work with padding would have to be dusty
indeed (fossilized?) if it used COMMON blocks that way.  It would
never have run on early RISCs, so it would likely have had a time
of non-use in the 1990s when RISCs ruled in price/performance
after mainframes and the VAX fell behind.

One point, using unaligned access on an x86 with a LOCK prefixed instruction will trigger a bus lock. Think of a word that straddles two l2 cache lines.