Code generation for load/store packed data
Nicolau Bogoevich
I am very interested in to know how compilers generate optimized code
for loading or storing data at unaligned memory locations and that
located inside bitfields (i. e., like that generated by using GNU C
"packed attribute" or packed ANSI C bitfield type definitions).
I suppose that is a well-known subject that was solved by somebody a
long time ago. Do you know some well-known technique or literature
about that subject? I would appreciate some pointers.
Thanks in advance!
cr88192
> I am very interested in to know how compilers generate optimized code
> for loading or storing data at unaligned memory locations and that
> located inside bitfields (i. e., like that generated by using GNU C
> "packed attribute" or packed ANSI C bitfield type definitions).
This is fairly arch specific I think, but on x86 at least, the most
efficient way to access unaligned data is just the same as aligned
data: directly. there may be a slight cost, but I don't know of any
other way that has less cost (and if there were, the implementors
would likely have done it...).
AFAIK, the usual RISC way is to do aligned accesses, and use shifts
and similar to recombine the results (since these archs often lack the
ability to access unaligned memory).
BTW, I think I read before that people had used this to good effect, namely
on older M68K systems, where a misaligned read could be used to cheaply read
little-endian values (I forget if this was a processor or bus issue though).
as for bitfields, the usual approach is shifting and masking (bitfields
being, as such, merged into integers or similar).
> I suppose that is a well-known subject that was solved by somebody a
> long time ago. Do you know some well-known technique or literature
> about that subject? I would appreciate some pointers.
p=&(((byte *)0xA0000)[y*xs+x]);
for(i=0; i<h; i++)for(j=0; j<w; j++)
p[i*xs+j]=clr;
....
yes, one need learn not to ask for 'pointers' when other coders are
around...