apparently impossible to compose blended code with would perform
satisfactory on all x86 and x86_64 cores, an extra RC4_CHAR
code-path is introduced and P4 core is detected at run-time. This
way we keep original performance on non-P4 implementations and
turbo-charge P4 performance by factor of 2.8x (on 32-bit core).

COFF and a.out targets [similar to ELF targets]. You might notice some
rudementary support for shared mingw builds under cygwin. It works (it
produces cryptoeay32.dll and ssleay32.dll with everything exported by
name), but it's primarily for testing/debugging purposes, at least for
now...

is to have a placeholder to small routines, which can be written only
in assembler. In IA-32 case this includes processor capability
identification and access to Time-Stamp Counter. As discussed earlier
OPENSSL_ia32cap is introduced to control recently added SSE2 code
pathes (see docs/crypto/OPENSSL_ia32cap.pod). For the moment the
code is operational on ELF platforms only. I haven't checked it yet,
but I have all reasons to believe that Windows build should fail to
link too. I'll be looking into it shortly...

Win64 comes in two flavors, IA-64/Itanium and AMD64/Opteron. The
suggestion is to refer to former as WIN64I and latter - WIN64A

both vendor and GNU compilers. ./engine shared build are still busted.
I mean always were...

especially for AIX. But most important BIGNUM assembler implementation
submitted by IBM.

Submitted by: Peter Waltenberg <pwalten@au1.ibm.com>
Reviewed by: appro

make update

this and a few other changes.

be modified to choose it instead of hpux64-parisc-gcc, which should
then be removed. hpux64-parisc-cc is removed already now as redundant
[in case you wonder, 64-bit HP-UX ABI *implies* PA-RISC2.0].

make update

Reportedly this option is deprecated, and on some systems
"make test" fails if it is included.

PR: 495

Submitted by:
Reviewed by:
PR: