[sldev] [VWR] OpenJPEG backtraces (Robin Cornelius)

Argent Stonecutter secret.argent at gmail.com
Sat Sep 22 08:48:25 PDT 2007


On 22-Sep-2007, at 09:38, Dzonatas wrote:
> 16 byte boundaries are needed for SSE. The instructions just before  
> it add the pad, which is just once and a little bit for the entire  
> image. The alignment in that part is not mandatory but helps avoid  
> non 16 byte aligned pointers later on.

Then there's another bug, because if it's already aligned the  
original code will add an unnecessary 16 byte gap.

Eg:

Let's say m is 0xA0000000. m + 16 is 0xA0000010. m % 16 is 0. So the  
result of aligning it is 0xA0000010, not 0xA0000000.

Adding 0x0F and masking with ~0x0F always does the right thing.

On the other hand...
> Some compilers don't allow that to happen, so you cast them to  
> unsigned.

Some compilers don't allow what to happen?

Adding an integer to a pointer ALWAYS works, even on word-addressed  
machines and machines with non-power-of-two word size.

I could see pointer masking being a problem, though I'd like to know  
of any compilers on machines newer than a DECsystem-20 where this  
would be a problem.

Anyway, I think the maximally portable code is this:

(int *)( (char *)m + ( 16 - ((unsigned)m % 16) ) % 16 )

You could explicitly mask here but any compiler that doesn't produce  
the same code for (uns % 16) and (uns & 0xF) has problems.

Now...does this work? Well, m cast to unsigned might truncate, but  
since it's immediately truncated again to 4 bits that doesn't matter.  
Then the second mask takes care of the case of m already being  
aligned. Then you're adding a pointer to an integer, which is portable.

If this is only done once it's not worth saving the extra mask.


More information about the SLDev mailing list