Processing unaligned data in an aligned fashion always requires some
data copying.
There's two different problems, each with a slightly different solution.
#1: input data must be word-aligned but can be processed per byte.
Assume wordsize=8, then an unaligned data input of length = 21 can be cut up as
1 2 3 || 4 5 6 7 8 9 0 1 | 2 3 4 5 6 7 8 9 || 0 1
so three calls: process three bytes (unaligned), 2*8 aligned, then 2
bytes unaligned at the end.
No data copying required (unless maybe for the head and tail). Just
needs two calls: one for aligned, one for unaligned.
#2 (and this is what the crypto hardware needs!) not only must the
input be word-aligned, its *length*
must also be word-aligned. (That's where 'padding' comes in)
wordsize=8, input length = 21, then the solution is QUITE different:
1 2 3 | 4 5 6 7 8 9 0 1 | 2 3 4 5 6 7 8 9 | 0 1
must be *moved* (copy is fine too ;-) ) to an _aligned_ buffer, i.e.
-> 1 2 3 4 5 6 7 8 | 9 0 1 2 3 4 5 6 | 7 8 9 0 1
and padded:
-> 1 2 3 4 5 6 7 8 | 9 0 1 2 3 4 5 6 | 7 8 9 0 1 p p p |
so it can be fed to the process. (You may exchange the padding and
aligning steps, of course. (Proof thereof is left as an exercise to
the reader.))
One note: type casting doesn't modify the pointer value (check your
ANSI/ISO C89/C99 standard references). What you need is data at an
'aligned pointer'.
For this, there's a way too:
get a buffer somewhere (malloc() or stack); we will assume this buffer
is unaligned, then align it as needed.
Hence to process W words, the size of the buffer MUST be W words PLUS
extra (wordsize-1) bytes, to allow for aligning the pointer.
Same code off the top of my head (bugs in it come free):
// for C89:
typedef unsigned char byte;
void process_unaligned_data_in_aligned_fashion
( void *src /* unaligned source */
, size_t srclen /* ASSUME padding has already been taken care of:
this one is already 'wordsize' aligned.
VALUE is therefor in WORDS, _NOT_ bytes! */
, int wordsize )
{
size_t buflen;
/* allocate buffer for aligning; allow for unaligned result: */
void *rawptr = OPENSSL_malloc(srclen * wordsize + wordsize - 1);
/* calc aligned pointer for target buf: shift UP */
int shift = wordsize;
shift -= ((int)rawptr) % wordsize;
byte *al_ptr = (byte *)rawptr;
al_ptr += shift;
/* now al_ptr is aligned at 'wordsize' aligned memory address */
memcpy(al_ptr, src, srclen * wordsize);
/* perform word-aligned operation: */
do_aligned_thing();
...
So far, 'C class 102'. ;-)
I am sure you'll be able to glean the relevant parts from this and
deduce how and which bits must be applied to your particular problem.
Sigh. Too bad you're not on M68K hardware or other machinery which
simply (and quite fatally) bombs out on you at a hardware level when
addressing words at UNaligned boundaries. Ah, those were the days...
Java doesn't care any more. (Oops, sorry. let's stop this rant in its
tracks!)
If you run on Intel (and you very probably are), you don't get that
penalty, so (performance degrading!) unaligned word accesses will
'work'. Combine this with your given fault description, then consider
that 'aligning the data' /may/ not be the answer you seek -- mark the
mention of the padding in passing. Consider it a hint that other
things may be wrong with your code. (hint != answer)
On Wed, Dec 10, 2008 at 1:51 PM, Vishnu Param <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> This is the HASH_BLOCK_DATA_ORDER (../crypto/sha/sha_locl.h) function
> prototype :
> static void HASH_BLOCK_DATA_ORDER (SHA_CTX *c, const void *p, size_t num)
>
> As I have mentioned before in a previous thread, I am trying to modify this
> function to use my own code in my crappy embedded system for my university
> project.
>
> I am using this for my input data :
> unsigned long *data = (unsigned long *)p;
>
> Most of the time, my custom function works. But when OpenSSL passes a non
> 32-bit alligned address, my calculations will go wrong. So my data is not
> alligned to the byte boundary. How do I compile OpenSSL to align itself to
> 32-bit boundaries?
>
> I know I can solve this easily by just working with bytes, but then my
> function will be slower than OpenSSL. Any ideas?
>
> Regards,
> Vishnu.
>
> ________________________________
> Enrich your blog with Windows Live Writer. Windows Live Writer
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
