>> There are alternatives for
>> x86[_64] platforms [besides AES-NI], namely SSSE3 vpaes-x86[_64] and
>> bsaes-x86_64 modules. These are accessible through EVP and provide
>> adequate performance (in comparison to aes_core.c that is, not AES-NI).
> 
> Thanks for pointing me at vpaes code. I've tested it and got two
> contrary results: on Core2, all the timing are worse (619-510-840-591)
> than mine (279-400-732-385). On Core i5 Lynnfield, the results are best
> I've ever seen (354-242-442-291). I guess the difference is because of
> use of pshufb instruction.

Correct, it's very sensitive to pshufb performance. Not that it's very
interesting, but in case you wonder Ivy Bridge delivers ~8% better
performance. BTW, if you have AMD Bobcat, I'd be very interested to see
the result.

> Anyway, vpaes is very interesting code.

Credit is due to Mike Hamburg.

>> It's not the fact that tables reside in code segment that requires extra
>> register, but the fact that the code itself is *position independent*. I
>> mean you can 'mov ebp,_Td2[ebp*]' even if _Td2 is in code segment
> 
> Andy, unfortunately I don't quite understand. Can you please show me the
> small example on perlasm of accessing constant table if there no free
> register?

??? &mov ("ebp",&DWP("Td2","","ebp",4)); and it doesn't matter where Td2
is. But once again, it's not position-independent, because if shared
module is loaded at alternative location, instruction will have to be
adjusted to point at new Td2 location. Position-independent code on the
other hand goes like "get address of next instruction [on x86 by calling
next instruction and popping value from stack], and then use *offset* to
Td4 to compose Td4's address in register". This way even if shared
module is loaded at alternative location, instruction doesn't need
adjustment, because *offset* to Td4 doesn't change.

On side note, one can argue that &DWP could have recognized
&DWP("Td2","ebp",4) by examining number of arguments and checking if
last one is number, thus making it more intuitive...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to