[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Hmm, then I guess we should use ints internally to hold single pixel
> values but retain unsigned longs wherever needed in the interface for
> API compatibility?
Seems reasonable. And this wouldn't pessimize, since integers < 64-bit are
promoted to 64-bit (full word size) at function boundaries in any reasonable
64-bit ABI.
> If you could explain your thinking about the alignment a bit more, that
> would be great. To me it seems like there is not much difference
> between dereferencing a 32-bit quantity and (i) storing it into a 32-bit
> register, or (ii) storing it into a 64-bit register. Surely the only
> difference is that in the latter case the upper 32-bits of the register
> need to be cleared (or sign-extended)?
The problem occurs when reading from memory. For example:
struct BITMAP {
...
char *line[256];
};
#define bmp_read32(addr) (*((unsigned long *)(addr)))
unsigned long getpixel32(struct BITMAP *b, int x, int y)
{
return bmp_read32(b->line[y]+4*x);
}
Nothing guarantees that b->line[y]+4*x will be a multiple of 8 and,
actually, it will not be for every other pixel.
On AMD64, if the memory is not aligned, the 64-bit load is split into two
32-bit loads so there is a slight penalty.
--
Eric Botcazou