Mail Archives: djgpp/1999/08/06/03:53:33
On Thu, 5 Aug 1999, Duncan Coutts wrote:
> These optimisations obviously should only be considered
> when doing assembly optimisation of time critical loops
> (such as matrix and vector operations in a 3D graphics
> pipeline).
>
> Does anyone have any suggestions on how to do the
> memory alignment? Are there any compiler exensions
> similar to __atribute__ ((packed)) ?
I don't understand. You say above that this is only important in
assembly code, so why do you care about compiler extensions?
In assembly, use something like ".balign 16,,7" before function entry
points and labels that are used in loops and jumps.
If you want to produce 16-byte aligned code from GCC, you can use the
-falign-* switches (see the GCC docs). Note that currently, GCC cannot
be told to use smart alignment as above, so you will waste some cycles
due to excess alignment. Future versions of GCC will be smarter about
alignment.
Also, note that without reconfiguring Binutils for 16-byte alignment, you
won't gain anything by aligning your code, because current Binutils ports
are configured for 4-byte alignment of subsections. Work is under way to
bump up alignment in future ports of Binutils, but there some
complications in C++ programs that make this not entirely trivial.
> I know gcc aligns
> data on the stack, however I suspect that it would not be
> possible to force 8 byte alignment for local variables or
> parameters.
The DJGPP startup code aligns the stack on 8-byte boundary, so unles you
need more alignment for automatic variables, you shouldn't worry about
the stack.
> Dynamic storage seems the only other possibility.
> The new operator aligns allocations to 4 byte boundaries.
Are you sure? malloc aligns on 8-byte boundary, so how come new doesn't?
- Raw text -