fast checking for alignment

i need to pre-increment a pointer to be 16B aligned for use with sse2 functions, but i am somewhat concerned about the repeated use of the modulus. i have heard it is possible to check for alignment with the & operator, but i can't seem to get that to work.

Code:

//...
unsigned char* index1 = memberDataBlock;
unsigned char* index2 = someOtherDataBlock;

while(index1%16||index2%16)
{
    *index1++ |= *index2++;
}

//...

is there a faster way to achieve the condition above other than using the modulus? i don't need the actual remainder, i just need to know if there is one or not.


please feel free to move this to the C forum if it is deemed more appropriate

"while (index1&0xF)" perhaps?

aaaah yes. your use of hex has made my careless error immediately obvious.

index&0xF , not index&16

edit: thanks!

Originally Posted by m37h0d

i need to pre-increment a pointer to be 16B aligned for use with sse2 functions, but i am somewhat concerned about the repeated use of the modulus. i have heard it is possible to check for alignment with the & operator, but i can't seem to get that to work.

Code:

//...
unsigned char* index1 = memberDataBlock;
unsigned char* index2 = someOtherDataBlock;

while(index1%16||index2%16)
{
    *index1++ |= *index2++;
}

Nice infinite loop you have there. (The only way it isn't infinite is if index1 & 0xF == index2 & 0xF)

you sure?

Code:

while(index1&0xF||index2&0xF)

"seems to work" /famous last words

The only way it isn't infinite is if index1 & 0xF == index2 & 0xF

and yes, if i want them both to be 16 byte aligned, isn't that exactly the condition i'm looking for? O_o

Originally Posted by m37h0d

you sure?

Code:

while(index1&0xF||index2&0xF)

"seems to work"

I'm with you. (This assumes that you only care about one of them being aligned. If you need them both to be aligned, then things could get rough.)

yes, i need them both aligned. and brewbuck's right. the addresses in my test just happened to be 16B aligned already.

Originally Posted by m37h0d

yes, i need them both aligned. and brewbuck's right. the addresses in my test just happened to be 16B aligned already.

If you need them both aligned, and they are not already co-aligned to 16 bytes, then you cannot do it. You will either need to copy one data set to a location where it is 16-byte aligned, or use SSE2 shuffle instructions combined with an extremely hard-to-understand inner loop to handle the misalignment. Lastly, you could use the unaligned store/load which, while slower, might still be faster than the other two alternatives.

It's extremely difficult to write efficient SIMD algorithms when you aren't in control of the original alignment.

in this case, i can be, but it may not be the case forever. the buffers in this case are data buffers for a piece of hardware. the driver for the particular piece of equipment has an option to use a user-defined buffer. future HW selections may not; thus necessitating nasty superfluous memcpys. i doubt that's really much of an issue though, because this is honestly the first piece of hw i've seen whose driver attempts to manage it's own memory on the client side.

Originally Posted by m37h0d

in this case, i can be, but it may not be the case forever. the buffers in this case are data buffers for a piece of hardware. the driver for the particular piece of equipment has an option to use a user-defined buffer. future HW selections may not; thus necessitating nasty superfluous memcpys. i doubt that's really much of an issue though, because this is honestly the first piece of hw i've seen whose driver attempts to manage it's own memory on the client side.

Most hardware buffers I've ever seen are at least 16-byte aligned and possibly quite a bit more. Particularly hardware buffers which are intended for direct memory mapping, are usually page-aligned. Hardware designers like alignment just as much as you do

yes, curious that it invariably was 16+B aligned, but the documentation doesn't guarantee it.

sadly the user-buffer option is not working according to spec :grumble: