Commenting below ...

This patchset is against OpenSSL 1.0.1c.

Whatever we will do, will apply to HEAD and optionally 1.0.2. 1.0.1 is closed 
for new features, including new platforms,
and linux-generic32 is the one that serves MIPS there.

Ok, not a problem ... more about future support, I can maintain my own patch 
for 1.0.1.
linux-generic32 doesn't include the mips assembler, so that would be undesirable
for my purposes.

It does 2 things very minor things.

First, it adds a linux-mipsel target to Configure.

What's your target more specifically? You mention 4ksd in commentary, is it it? 
Do you have something else? The thing
about linux-mips is that [as far as I understand] there are n32 dists, and n32 
allows for much faster bignum and sha512
assembler. I don't know if there is 64-bit linux for MIPS, but it makes sense to reserve 
at least for "plain" o32 and
n32. Latter can run on processors compliant with mips3, mips4, mips64 and 
mips64r2 specifications.

This is the processor I'm running, it is a 32bit 96MHz MIPS 4ksd processor:
http://www.maximintegrated.com/datasheet/index.mvp/id/6134

I'm not the manufacturer of the device being used, we were just given a
cross-compiler for the mipsel-linux uclibc environment the device runs, and
were asked to see if we could port our application to the environment with
reasonable performance.

It looks like n32 is for 64bit CPUs only, so I'm assuming I'm using o32.

As for 4ksd. It appears to be mips32r2 processor, and even with SmartMIPS ASE. 
Actually on r2 compiler has all chances
to beat currently available assembler, if it recognizes rotates and deploys 
rotate instruction. I have r2 code, and
wonder if you can test and benchmark it. SmartMIPS extension offers improved 
support for bignum and polynomial
multiplication, but I have no code for it.

I can definitely test and benchmark whatever you want on the platform,
I'm definitely willing to try out any new code you may have.

The device is definitely a bit anemic from a performance standpoint,
SSL negotiation (where the device is the server) takes about 2s
as it currently stands, and that's with the current MIPS assembler
support in OpenSSL.

I was planning on running some actual benchmarks but hadn't gotten
around to it yet.


Second, it fixes the MIPS perlasm, it appears as though at some point
AES_set_encrypt_key and AES_set_decrypt_key in the ASM needed to be
renamed to private_AES_set_encrypt_key and private_AES_set_decrypt_key,
respectively and MIPS got missed.

This was recently fixed.

Ah, I missed that.

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

Reply via email to