[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