>> 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