>>> In Debian we ship several versions of the shared libraries on i386. >>> One that's build the default instruction set of that architecture >>> (which is still i486 I think), and then 2 optimised versions, >>> one for 586 and one for 686. The 586 and 686 versions use the >>> assembler and so have AES_ASM defined. The dynamic linker picks >>> the proper shared library depending on the CPU. >> Why don't you compile assembler even in "default instruction set" build? >> Even though modules are called 586, they run even on 486 (and can be >> compiled for 386). 586 is merely a reference to the way instructions >> were scheduled at some point in time, now it effectively lost the >> meaning. Moreover, I'd argue that single assembler build is sufficient, >> because a) assembler code detects processor it executes on; b) potential > > As far as I know, this detection is not supported on a real 486.
Have a look at the beginning of crypto/x86cpuid.pl. You'll notice bunch of pushf and popf. What are they about? They are about detecting pre-586 processor! In other words detection *is* supported on real 486 and procedure should return 0 denoting fully incapable processor. Assembler is supported even on 486 in sense that if problem is reported, it won't be dismissed. I've double-checked x86cpuid in HEAD and 1.0.1 and it turned that I've carried away and broke it on pre-586. Fixed now, http://cvs.openssl.org/chngview?cn=22178. 1.0.0 and 0.9.8 work as is. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
