diff options
author | Andy Polyakov <appro@openssl.org> | 2009-03-16 13:48:42 +0000 |
---|---|---|
committer | Andy Polyakov <appro@openssl.org> | 2009-03-16 13:48:42 +0000 |
commit | 57db09906be76c39ec157920936b080489d1139f (patch) | |
tree | 7deef2096f25fc540c9686f69e69619f7a3d0c6c /crypto/sha/asm | |
parent | 4c78bc05c44ca16daaf5a568eedd0fee700f5de8 (diff) |
Excuse myself from integrating sha1-sparcv9a.pl into build system, but
make it Purify-friendly...
Diffstat (limited to 'crypto/sha/asm')
-rw-r--r-- | crypto/sha/asm/sha1-sparcv9a.pl | 64 |
1 files changed, 36 insertions, 28 deletions
diff --git a/crypto/sha/asm/sha1-sparcv9a.pl b/crypto/sha/asm/sha1-sparcv9a.pl index be7da91e48..9e8d0ca382 100644 --- a/crypto/sha/asm/sha1-sparcv9a.pl +++ b/crypto/sha/asm/sha1-sparcv9a.pl @@ -22,6 +22,12 @@ # 40% over pure IALU sha1-sparcv9.pl on UltraSPARC-IIi, but 12% on # UltraSPARC-III. See below for discussion... # +# The module does not present direct interest for OpenSSL, because +# it doesn't provide better performance on contemporary SPARCv9 CPUs, +# UltraSPARC-Tx and SPARC64-V[II] to be specific. Those who feel they +# absolutely must score on UltraSPARC-I-IV can simply replace +# crypto/sha/asm/sha1-sparcv9.pl with this module. +# # (*) "Pipe-lined" means that even if it takes several cycles to # complete, next instruction using same functional unit [but not # depending on the result of the current instruction] can start @@ -100,21 +106,26 @@ ___ # The numbers delimited with slash are the earliest possible dispatch # cycles for given instruction assuming 1 cycle latency for simple VIS # instructions, such as on UltraSPARC-I&II, 3 cycles latency, such as -# on UltraSPARC-III&IV, and 2 cycles latency, such as on SPARC64-V[?], -# respectively. Being 2x-parallelized the procedure is "worth" 5, 8.5 -# or 6 ticks per SHA1 round. As FPU/VIS instructions are perfectly -# pairable with IALU ones, the round timing is defined by the maximum -# between VIS and IALU timings. The latter varies from round to round -# and averages out at 6.25 ticks. This means that USI&II and SPARC64-V -# should operate at IALU rate, while USIII&IV - at VIS rate. This -# explains why performance improvement varies among processors. Well, -# it should be noted that pure IALU sha1-sparcv9.pl module exhibits -# virtually uniform performance of ~9.3 cycles per SHA1 round. Timings -# mentioned above are theoretical lower limits. Real-life performance -# was measured to be 6.6 cycles per SHA1 round on USIIi and 8.3 on -# USIII. The latter is lower than half-round VIS timing, because there -# are 16 Xupdate-free rounds, which "push down" average theoretical -# timing to 8 cycles... +# on UltraSPARC-III&IV, and 2 cycles latency(*), respectively. Being +# 2x-parallelized the procedure is "worth" 5, 8.5 or 6 ticks per SHA1 +# round. As [long as] FPU/VIS instructions are perfectly pairable with +# IALU ones, the round timing is defined by the maximum between VIS +# and IALU timings. The latter varies from round to round and averages +# out at 6.25 ticks. This means that USI&II should operate at IALU +# rate, while USIII&IV - at VIS rate. This explains why performance +# improvement varies among processors. Well, given that pure IALU +# sha1-sparcv9.pl module exhibits virtually uniform performance of +# ~9.3 cycles per SHA1 round. Timings mentioned above are theoretical +# lower limits. Real-life performance was measured to be 6.6 cycles +# per SHA1 round on USIIi and 8.3 on USIII. The latter is lower than +# half-round VIS timing, because there are 16 Xupdate-free rounds, +# which "push down" average theoretical timing to 8 cycles... + +# (*) SPARC64-V[II] was originally believed to have 2 cycles VIS +# latency. Well, it might have, but it doesn't have dedicated +# VIS-unit. Instead, VIS instructions are executed by other +# functional units, ones used here - by IALU. This doesn't +# improve effective ILP... } # The reference Xupdate procedure is then "strained" over *pairs* of @@ -124,7 +135,7 @@ ___ # to fetch and align input for the next spin. The VIS instructions are # scheduled for latency of 2 cycles, because there are not enough IALU # instructions to schedule for latency of 3, while scheduling for 1 -# would give no gain on USI&II, but loss on SPARC64-V. +# would give no gain on USI&II anyway. sub BODY_00_19 { my ($i,$a,$b,$c,$d,$e)=@_; @@ -397,25 +408,21 @@ vis_const: .align 64 .type vis_const,#object .size vis_const,(.-vis_const) -load_vis_const: - ldd [$tmp0+0],$VK_00_19 - ldd [$tmp0+8],$VK_20_39 - ldd [$tmp0+16],$VK_40_59 - ldd [$tmp0+24],$VK_60_79 - retl - ldd [$tmp0+32],$fmul -.type load_vis_const,#function -.size load_vis_const,(.-load_vis_const) -.align 32 .globl sha1_block_data_order sha1_block_data_order: save %sp,-$frame,%sp add %fp,$bias-256,$base -1: call load_vis_const +1: call .+8 sub %o7,1b-vis_const,$tmp0 + ldd [$tmp0+0],$VK_00_19 + ldd [$tmp0+8],$VK_20_39 + ldd [$tmp0+16],$VK_40_59 + ldd [$tmp0+24],$VK_60_79 + ldd [$tmp0+32],$fmul + ld [$ctx+0],$Actx and $base,-256,$base ld [$ctx+4],$Bctx @@ -487,7 +494,8 @@ for (;$i<40;$i++) { &BODY_20_39($i,@V); unshift(@V,pop(@V)); } for (;$i<60;$i++) { &BODY_40_59($i,@V); unshift(@V,pop(@V)); } for (;$i<70;$i++) { &BODY_20_39($i,@V); unshift(@V,pop(@V)); } $code.=<<___; - brz,pn $len,.Ltail + tst $len + bz,pn `$bits==32?"%icc":"%xcc"`,.Ltail nop ___ for (;$i<80;$i++) { &BODY_70_79($i,@V); unshift(@V,pop(@V)); } |