Re: Code generation for load/store packed data

"cr88192" <>
Mon, 12 May 2008 18:32:51 +1000

          From comp.compilers

Related articles
Code generation for load/store packed data (Nicolau Bogoevich) (2008-05-11)
Re: Code generation for load/store packed data (cr88192) (2008-05-12)
| List of all articles for this month |

From: "cr88192" <>
Newsgroups: comp.compilers
Date: Mon, 12 May 2008 18:32:51 +1000
Organization: Saipan Datacom
References: 08-05-033
Keywords: storage, optimize
Posted-Date: 12 May 2008 20:58:36 EDT

"Nicolau Bogoevich" <> wrote in message

> 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++)

yes, one need learn not to ask for 'pointers' when other coders are

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.