Re: [AD] AMD64 patch

[Peter Wang <tjaden@xxxxxxxxxx>]

Eric Botcazou wrote:

> > 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.
>  

Great.

> > 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.
>  

Ok, that's fine.  Though I was more thinking of cases like these:

	uint32_t *p = bmp->line[y];
	for (...) {
		colour_t c = *p++;
		...
	}

The load is 32-bits here, so whether colour_t == unsigned long or colour_t == unsigned int should not make much difference, should it?


Peter