| blob | 85e8d68086bb700855ec3fedb5b17fba4a7a1464 |
1 #!/usr/bin/env perl
3 # ====================================================================
4 # Written by Andy Polyakov <appro@fy.chalmers.se> for the OpenSSL
5 # project. The module is, however, dual licensed under OpenSSL and
6 # CRYPTOGAMS licenses depending on where you obtain it. For further
7 # details see http://www.openssl.org/~appro/cryptogams/.
8 # ====================================================================
10 # January 2009
11 #
12 # Provided that UltraSPARC VIS instructions are pipe-lined(*) and
13 # pairable(*) with IALU ones, offloading of Xupdate to the UltraSPARC
14 # Graphic Unit would make it possible to achieve higher instruction-
15 # level parallelism, ILP, and thus higher performance. It should be
16 # explicitly noted that ILP is the keyword, and it means that this
17 # code would be unsuitable for cores like UltraSPARC-Tx. The idea is
18 # not really novel, Sun had VIS-powered implementation for a while.
19 # Unlike Sun's implementation this one can process multiple unaligned
20 # input blocks, and as such works as drop-in replacement for OpenSSL
21 # sha1_block_data_order. Performance improvement was measured to be
22 # 40% over pure IALU sha1-sparcv9.pl on UltraSPARC-IIi, but 12% on
23 # UltraSPARC-III. See below for discussion...
24 #
25 # The module does not present direct interest for OpenSSL, because
26 # it doesn't provide better performance on contemporary SPARCv9 CPUs,
27 # UltraSPARC-Tx and SPARC64-V[II] to be specific. Those who feel they
28 # absolutely must score on UltraSPARC-I-IV can simply replace
29 # crypto/sha/asm/sha1-sparcv9.pl with this module.
30 #
31 # (*) "Pipe-lined" means that even if it takes several cycles to
32 # complete, next instruction using same functional unit [but not
33 # depending on the result of the current instruction] can start
34 # execution without having to wait for the unit. "Pairable"
35 # means that two [or more] independent instructions can be
36 # issued at the very same time.
82 # This is reference 2x-parallelized VIS-powered Xupdate procedure. It
83 # covers even K_NN_MM addition...
89 # [ provided that GSR.alignaddr_offset is 5, $mul contains
90 # 0x100ULL<<32|0x100 value and K_NN_MM are pre-loaded to
91 # chosen registers... ]
105 ___
106 # The numbers delimited with slash are the earliest possible dispatch
107 # cycles for given instruction assuming 1 cycle latency for simple VIS
108 # instructions, such as on UltraSPARC-I&II, 3 cycles latency, such as
109 # on UltraSPARC-III&IV, and 2 cycles latency(*), respectively. Being
110 # 2x-parallelized the procedure is "worth" 5, 8.5 or 6 ticks per SHA1
111 # round. As [long as] FPU/VIS instructions are perfectly pairable with
112 # IALU ones, the round timing is defined by the maximum between VIS
113 # and IALU timings. The latter varies from round to round and averages
114 # out at 6.25 ticks. This means that USI&II should operate at IALU
115 # rate, while USIII&IV - at VIS rate. This explains why performance
116 # improvement varies among processors. Well, given that pure IALU
117 # sha1-sparcv9.pl module exhibits virtually uniform performance of
118 # ~9.3 cycles per SHA1 round. Timings mentioned above are theoretical
119 # lower limits. Real-life performance was measured to be 6.6 cycles
120 # per SHA1 round on USIIi and 8.3 on USIII. The latter is lower than
121 # half-round VIS timing, because there are 16 Xupdate-free rounds,
122 # which "push down" average theoretical timing to 8 cycles...
124 # (*) SPARC64-V[II] was originally believed to have 2 cycles VIS
125 # latency. Well, it might have, but it doesn't have dedicated
126 # VIS-unit. Instead, VIS instructions are executed by other
127 # functional units, ones used here - by IALU. This doesn't
128 # improve effective ILP...
129 }
131 # The reference Xupdate procedure is then "strained" over *pairs* of
132 # BODY_NN_MM and kind of modulo-scheduled in respect to X[n]^=X[n+13]
133 # and K_NN_MM addition. It's "running" 15 rounds ahead, which leaves
134 # plenty of room to amortize for read-after-write hazard, as well as
135 # to fetch and align input for the next spin. The VIS instructions are
136 # scheduled for latency of 2 cycles, because there are not enough IALU
137 # instructions to schedule for latency of 3, while scheduling for 1
138 # would give no gain on USI&II anyway.
167 ___
187 ___
190 ___
191 }
219 ___
239 ___
255 ___
269 ___
270 }
301 ___
322 ___
323 }
325 # If there is more data to process, then we pre-fetch the data for
326 # next iteration in last ten rounds...
354 ___
368 ___
384 ___
387 ___
392 ___
395 ___
396 }
402 vis_const:
412 .globl sha1_block_data_order
413 sha1_block_data_order:
487 ba .Loop
491 ___
497 tst $len
499 nop
500 ___
517 ba .Loop
522 ___
537 ret
538 restore
543 ___
545 # Purpose of these subroutines is to explicitly encode VIS instructions,
546 # so that one can compile the module without having to specify VIS
547 # extentions on compiler command line, e.g. -xarch=v9 vs. -xarch=v9a.
548 # Idea is to reserve for option to produce "universal" binary and let
549 # programmer detect if current CPU is VIS capable at run-time.
567 # re-encode for upper double register addressing
569 }
570 }
577 }
578 }
587 }
591 }