> 1) I note there is an edian flag but I do not understand at this point
> why it is present.  It is quite trivial for the software to determine
> the edian order of a CPU and to my way of thinking the user/installer
> should not be asked for information
You're not actually asked for it and moreover the flag is optional. If
you don't like it for any reason you can take it away, it won't break
the code.
> that the software can
> detect for itself at run time.
All algorithms are endian neutral and few (for the moment it's 32 bit
block message digests and soon RC4) are endian *aware*. Such awareness
made it possible to improve performance of algorithms in question under
certain circumstances. Speed-up factor varies from platform to platform,
in RISC cases - from 20% to 40%.
> 
> I would think there might be a very slight performance penatly but I
> doubt it would be more than 0.1% and probably an order of
> magnitude less.
Then you would end-up implementing twise as much code to choose between
at run-time and covering both endian cases. In order to be excused from
implementing the second case you will very likely to introduce some CPU
dependent #ifdef and it won't be any different from #ifdef [BL]_ENDIAN
anyway. Alternatively you would have to check endianness too often (in
most cases to guard a *signle* instruction) and would definitely harm
performance. Also note that some endian-dependent code is written in
assembler...
> 
> I will funrish a function to detect the endian order if requested.
int is_bigendian() { static int i=1; return (int)(*(char *)&i); }

In either case "roadmap" for [BL]_ENDIAN is to move it to the code
portion of the ./Configure script so that it will be determined
automatically. On the second thought ./config might be better place if
we want to let people run ./Configure on none-target computer (at least
I did so once myself)...

Andy.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to