userapps/opensource/openssl/crypto/rc4/asm/rc4-ia64.S

   1 // ====================================================================
   2 // Written by Andy Polyakov <appro@fy.chalmers.se> for the OpenSSL
   3 // project.
   4 //
   5 // Rights for redistribution and usage in source and binary forms are
   6 // granted according to the OpenSSL license. Warranty of any kind is
   7 // disclaimed.
   8 // ====================================================================
   9
  10 .ident  "rc4-ia64.S, Version 1.1"
  11 .ident  "IA-64 ISA artwork by Andy Polyakov <appro@fy.chalmers.se>"
  12
  13 // What's wrong with compiler generated code? Because of the nature of
  14 // C language, compiler doesn't [dare to] reorder load and stores. But
  15 // being memory-bound, RC4 should benefit from reorder [on in-order-
  16 // execution core such as IA-64]. But what can we reorder? At the very
  17 // least we can safely reorder references to key schedule in respect
  18 // to input and output streams. Secondly, from the first [close] glance
  19 // it appeared that it's possible to pull up some references to
  20 // elements of the key schedule itself. Original rationale ["prior
  21 // loads are not safe only for "degenerated" key schedule, when some
  22 // elements equal to the same value"] was kind of sloppy. I should have
  23 // formulated as it really was: if we assume that pulling up reference
  24 // to key[x+1] is not safe, then it would mean that key schedule would
  25 // "degenerate," which is never the case. The problem is that this
  26 // holds true in respect to references to key[x], but not to key[y].
  27 // Legitimate "collisions" do occur within every 256^2 bytes window.
  28 // Fortunately there're enough free instruction slots to keep prior
  29 // reference to key[x+1], detect "collision" and compensate for it.
  30 // All this without sacrificing a single clock cycle:-)
  31 // Furthermore. In order to compress loop body to the minimum, I chose
  32 // to deploy deposit instruction, which substitutes for the whole
  33 // key->data+((x&255)<<log2(sizeof(key->data[0]))). This unfortunately
  34 // requires key->data to be aligned at sizeof(key->data) boundary.
  35 // This is why you'll find "RC4_INT pad[512-256-2];" addenum to RC4_KEY
  36 // and "d=(RC4_INT *)(((size_t)(d+255))&~(sizeof(key->data)-1));" in
  37 // rc4_skey.c [and rc4_enc.c, where it's retained for debugging
  38 // purposes]. Throughput is ~210MBps on 900MHz CPU, which is is >3x
  39 // faster than gcc generated code and +30% - if compared to HP-UX C.
  40 // Unrolling loop below should give >30% on top of that...
  41
  42 .text
  43 .explicit
  44
  45 #if defined(_HPUX_SOURCE) && !defined(_LP64)
  46 # define ADDP   addp4
  47 #else
  48 # define ADDP   add
  49 #endif
  50
  51 #define SZ      4       // this is set to sizeof(RC4_INT)
  52 // SZ==4 seems to be optimal. At least SZ==8 is not any faster, not for
  53 // assembler implementation, while SZ==1 code is ~30% slower.
  54 #if SZ==1       // RC4_INT is unsigned char
  55 # define        LDKEY   ld1
  56 # define        STKEY   st1
  57 # define        OFF     0
  58 #elif SZ==4     // RC4_INT is unsigned int
  59 # define        LDKEY   ld4
  60 # define        STKEY   st4
  61 # define        OFF     2
  62 #elif SZ==8     // RC4_INT is unsigned long
  63 # define        LDKEY   ld8
  64 # define        STKEY   st8
  65 # define        OFF     3
  66 #endif
  67
  68 out=r8;         // [expanded] output pointer
  69 inp=r9;         // [expanded] output pointer
  70 prsave=r10;
  71 key=r28;        // [expanded] pointer to RC4_KEY
  72 ksch=r29;       // (key->data+255)[&~(sizeof(key->data)-1)]
  73 xx=r30;
  74 yy=r31;
  75
  76 // void RC4(RC4_KEY *key,size_t len,const void *inp,void *out);
  77 .global RC4#
  78 .proc   RC4#
  79 .align  32
  80 .skip   16
  81 RC4:
  82         .prologue
  83         .fframe 0
  84         .save   ar.pfs,r2
  85         .save   ar.lc,r3
  86         .save   pr,prsave
  87 { .mii; alloc   r2=ar.pfs,4,12,0,16
  88         mov     prsave=pr
  89         ADDP    key=0,in0               };;
  90 { .mib; cmp.eq  p6,p0=0,in1                     // len==0?
  91         mov     r3=ar.lc
  92 (p6)    br.ret.spnt.many        b0      };;     // emergency exit
  93
  94         .body
  95         .rotr   dat[4],key_x[4],tx[2],rnd[2],key_y[2],ty[1];
  96
  97 { .mib; LDKEY   xx=[key],SZ                     // load key->x
  98         add     in1=-1,in1                      // adjust len for loop counter
  99         nop.b   0                       }
 100 { .mib; ADDP    inp=0,in2
 101         ADDP    out=0,in3
 102         brp.loop.imp    .Ltop,.Lexit-16 };;
 103 { .mmi; LDKEY   yy=[key]                        // load key->y
 104         add     ksch=(255+1)*SZ,key             // as ksch will be used with
 105                                                 // deposit instruction only,
 106                                                 // I don't have to &~255...
 107         mov     ar.lc=in1               }
 108 { .mmi; mov     key_y[1]=r0                     // guarantee inequality
 109                                                 // in first iteration
 110         add     xx=1,xx
 111         mov     pr.rot=1<<16            };;
 112 { .mii; nop.m   0
 113         dep     key_x[1]=xx,ksch,OFF,8
 114         mov     ar.ec=3                 };;     // note that epilogue counter
 115                                                 // is off by 1. I compensate
 116                                                 // for this at exit...
 117 .Ltop:
 118 // The loop is scheduled for 3*(n+2) spin-rate on Itanium 2, which
 119 // theoretically gives asymptotic performance of clock frequency
 120 // divided by 3 bytes per seconds, or 500MBps on 1.5GHz CPU. Measured
 121 // performance however is distinctly lower than 1/4:-( The culplrit
 122 // seems to be *(out++)=dat, which inadvertently splits the bundle,
 123 // even though there is M-port available... Unrolling is due...
 124 // Unrolled loop should collect output with variable shift instruction
 125 // in order to avoid starvation for integer shifter... It should be
 126 // possible to get pretty close to theoretical peak...
 127 { .mmi; (p16)   LDKEY   tx[0]=[key_x[1]]                // tx=key[xx]
 128         (p17)   LDKEY   ty[0]=[key_y[1]]                // ty=key[yy]
 129         (p18)   dep     rnd[1]=rnd[1],ksch,OFF,8}       // &key[(tx+ty)&255]
 130 { .mmi; (p19)   st1     [out]=dat[3],1                  // *(out++)=dat
 131         (p16)   add     xx=1,xx                         // x++
 132         (p16)   cmp.ne.unc p20,p21=key_x[1],key_y[1]    };;
 133 { .mmi; (p18)   LDKEY   rnd[1]=[rnd[1]]                 // rnd=key[(tx+ty)&255]
 134         (p16)   ld1     dat[0]=[inp],1                  // dat=*(inp++)
 135         (p16)   dep     key_x[0]=xx,ksch,OFF,8  }       // &key[xx&255]
 136 .pred.rel       "mutex",p20,p21
 137 { .mmi; (p21)   add     yy=yy,tx[1]                     // (p16)
 138         (p20)   add     yy=yy,tx[0]                     // (p16) y+=tx
 139         (p21)   mov     tx[0]=tx[1]             };;     // (p16)
 140 { .mmi; (p17)   STKEY   [key_y[1]]=tx[1]                // key[yy]=tx
 141         (p17)   STKEY   [key_x[2]]=ty[0]                // key[xx]=ty
 142         (p16)   dep     key_y[0]=yy,ksch,OFF,8  }       // &key[yy&255]
 143 { .mmb; (p17)   add     rnd[0]=tx[1],ty[0]              // tx+=ty
 144         (p18)   xor     dat[2]=dat[2],rnd[1]            // dat^=rnd
 145         br.ctop.sptk    .Ltop                   };;
 146 .Lexit:
 147 { .mib; STKEY   [key]=yy,-SZ                    // save key->y
 148         mov     pr=prsave,0x1ffff
 149         nop.b   0                       }
 150 { .mib; st1     [out]=dat[3],1                  // compensate for truncated
 151                                                 // epilogue counter
 152         add     xx=-1,xx
 153         nop.b   0                       };;
 154 { .mib; STKEY   [key]=xx                        // save key->x
 155         mov     ar.lc=r3
 156         br.ret.sptk.many        b0      };;
 157 .endp   RC4#