+1. bit #4 denoting presence of Time-Stamp Counter.
+2. bit #20, reserved by Intel, is used to choose among RC4 code
+ paths;
+3. bit #23 denoting MMX support;
+4. bit #25 denoting SSE support;
+5. bit #26 denoting SSE2 support;
+6. bit #28 denoting Hyperthreading, which is used to distiguish
+ cores with shared cache;
+7. bit #30, reserved by Intel, is used to choose among RC4 code
+ paths;
+8. bit #57 denoting Intel AES instruction set extension;
+
+For example, clearing bit #26 at run-time disables high-performance
+SSE2 code present in the crypto library. You might have to do this if
+target OpenSSL application is executed on SSE2 capable CPU, but under
+control of OS which does not support SSE2 extentions. Even though you
+can manipulate the value programmatically, you most likely will find it
+more appropriate to set up an environment variable with the same name
+prior starting target application, e.g. on Intel P4 processor 'env
+OPENSSL_ia32cap=0x12900010 apps/openssl', to achieve same effect
+without modifying the application source code. Alternatively you can
+reconfigure the toolkit with no-sse2 option and recompile.
+
+Less intuituve is clearing bit #28. The truth is that it's not copied
+from CPUID output verbatim, but is adjusted to reflect whether or not
+the data cache is actually shared between logical cores. This in turn
+affects the decision on whether or not expensive countermeasures
+against cache-timing attacks are applied, most notably in AES assembler
+module.