Development of OpenSSL

Andy Polyakov via RT | 22 Aug 2012 19:49

Re: [openssl.org #2863] Mips build of 1.0.1 fails, no private_AES_encrypt_key

Duane,

On related matter. The modules were originally developed on IRIX and 
IRIX assembler has very nice feature: it's optimizing code depending on 
command line options. This allowed to maintain assembly modules more 
readable and let assembler rearrange instruction for optimal 
performance. But this means that it doesn't come out optimal if another 
assembler is used... Well, depending on CPU. For single-issue 
in-order-execution processors, order doesn't matter, but not for 
multiple-issue ones. So the question is if your target processors can 
issue more than one issue per cycle, and if so, would you like to test 
and benchmark updated code? Well, it won't be many times faster, but 10% 
is not impossible...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

headers

Sand, Duane | 30 Aug 2012 02:22

RE: [openssl.org #2863] Mips build of 1.0.1 fails, no private_AES_encrypt_key

Hi Andy,

The scheduling feature of the original Mips assemblers was very nice; I used it extensively in 1988.  It is
unfortunately not present in the gnu and llvm assemblers now commonly used by most current users of the
Mips architecture.  The static schedule in this existing code looks good to me.  Current mips systems have a
variety of pipelines:  single-issue in-order, dual-issue in-order, and multi-issue with dynamic
scheduling.  Code tuned this way for the R5000 is still pretty good for all.  There are some new extract
opcodes that could maybe eliminate some masking steps.   There might be an opportunity to replace most
swl/swr pairs by aligned sw's.  If we see these routines pop up on Android performance profiles, we'll take
another look.

thanks,
     Duane 

________________________________________
From: Andy Polyakov via RT [rt <at> openssl.org]
Sent: Wednesday, August 22, 2012 10:49 AM
To: Sand, Duane
Cc: openssl-dev <at> openssl.org
Subject: Re: [openssl.org #2863] Mips build of 1.0.1 fails, no private_AES_encrypt_key

Duane,

On related matter. The modules were originally developed on IRIX and
IRIX assembler has very nice feature: it's optimizing code depending on
command line options. This allowed to maintain assembly modules more
readable and let assembler rearrange instruction for optimal
performance. But this means that it doesn't come out optimal if another
assembler is used... Well, depending on CPU. For single-issue
in-order-execution processors, order doesn't matter, but not for

(Continue reading)

headers

Sand, Duane via RT | 30 Aug 2012 02:22

RE: [openssl.org #2863] Mips build of 1.0.1 fails, no private_AES_encrypt_key

Hi Andy,

The scheduling feature of the original Mips assemblers was very nice; I used it extensively in 1988.  It is
unfortunately not present in the gnu and llvm assemblers now commonly used by most current users of the
Mips architecture.  The static schedule in this existing code looks good to me.  Current mips systems have a
variety of pipelines:  single-issue in-order, dual-issue in-order, and multi-issue with dynamic
scheduling.  Code tuned this way for the R5000 is still pretty good for all.  There are some new extract
opcodes that could maybe eliminate some masking steps.   There might be an opportunity to replace most
swl/swr pairs by aligned sw's.  If we see these routines pop up on Android performance profiles, we'll take
another look.

thanks,
     Duane 

________________________________________
From: Andy Polyakov via RT [rt <at> openssl.org]
Sent: Wednesday, August 22, 2012 10:49 AM
To: Sand, Duane
Cc: openssl-dev <at> openssl.org
Subject: Re: [openssl.org #2863] Mips build of 1.0.1 fails, no private_AES_encrypt_key

Duane,

On related matter. The modules were originally developed on IRIX and
IRIX assembler has very nice feature: it's optimizing code depending on
command line options. This allowed to maintain assembly modules more
readable and let assembler rearrange instruction for optimal
performance. But this means that it doesn't come out optimal if another
assembler is used... Well, depending on CPU. For single-issue
in-order-execution processors, order doesn't matter, but not for

(Continue reading)