Since you are more familiar - give me an example of endian dependant code. I'll have
a look, if it looks feasible ai"ll do a
simple modification and then we can test the difference. Without knowing specifically
where the mods need to take place and
what the code looks like, I can't speculate on what the penalty might be.
I do know that I implemented a complete system inculding 1000's of lines of code and
enidan issues were collected in such a
small part of the code that they were basically irrelevant. This may not be the case
here.
So all I'll need are the names of a couple affected functions. If I'm to do more than
just a quick survey of the potential impact, I'll
need the current sourse tree as well - but that can wait and I can do my testing on
the version I presently have.
Thanks.
On Sat, 25 Sep 1999 13:57:33 +0200, Andy Polyakov wrote:
>> 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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
