| OLD | NEW |
|---|
| (Empty) |
| 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 2.0" | |
| 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:-) Throughput is | |
| 31 // ~210MBps on 900MHz CPU, which is is >3x faster than gcc generated | |
| 32 // code and +30% - if compared to HP-UX C. Unrolling loop below should | |
| 33 // give >30% on top of that... | |
| 34 | |
| 35 .text | |
| 36 .explicit | |
| 37 | |
| 38 #if defined(_HPUX_SOURCE) && !defined(_LP64) | |
| 39 # define ADDP addp4 | |
| 40 #else | |
| 41 # define ADDP add | |
| 42 #endif | |
| 43 | |
| 44 #ifndef SZ | |
| 45 #define SZ 4 // this is set to sizeof(RC4_INT) | |
| 46 #endif | |
| 47 // SZ==4 seems to be optimal. At least SZ==8 is not any faster, not for | |
| 48 // assembler implementation, while SZ==1 code is ~30% slower. | |
| 49 #if SZ==1 // RC4_INT is unsigned char | |
| 50 # define LDKEY ld1 | |
| 51 # define STKEY st1 | |
| 52 # define OFF 0 | |
| 53 #elif SZ==4 // RC4_INT is unsigned int | |
| 54 # define LDKEY ld4 | |
| 55 # define STKEY st4 | |
| 56 # define OFF 2 | |
| 57 #elif SZ==8 // RC4_INT is unsigned long | |
| 58 # define LDKEY ld8 | |
| 59 # define STKEY st8 | |
| 60 # define OFF 3 | |
| 61 #endif | |
| 62 | |
| 63 out=r8; // [expanded] output pointer | |
| 64 inp=r9; // [expanded] output pointer | |
| 65 prsave=r10; | |
| 66 key=r28; // [expanded] pointer to RC4_KEY | |
| 67 ksch=r29; // (key->data+255)[&~(sizeof(key->data)-1)] | |
| 68 xx=r30; | |
| 69 yy=r31; | |
| 70 | |
| 71 // void RC4(RC4_KEY *key,size_t len,const void *inp,void *out); | |
| 72 .global RC4# | |
| 73 .proc RC4# | |
| 74 .align 32 | |
| 75 .skip 16 | |
| 76 RC4: | |
| 77 .prologue | |
| 78 .save ar.pfs,r2 | |
| 79 { .mii; alloc r2=ar.pfs,4,12,0,16 | |
| 80 .save pr,prsave | |
| 81 mov prsave=pr | |
| 82 ADDP key=0,in0 };; | |
| 83 { .mib; cmp.eq p6,p0=0,in1 // len==0? | |
| 84 .save ar.lc,r3 | |
| 85 mov r3=ar.lc | |
| 86 (p6) br.ret.spnt.many b0 };; // emergency exit | |
| 87 | |
| 88 .body | |
| 89 .rotr dat[4],key_x[4],tx[2],rnd[2],key_y[2],ty[1]; | |
| 90 | |
| 91 { .mib; LDKEY xx=[key],SZ // load key->x | |
| 92 add in1=-1,in1 // adjust len for loop counter | |
| 93 nop.b 0 } | |
| 94 { .mib; ADDP inp=0,in2 | |
| 95 ADDP out=0,in3 | |
| 96 brp.loop.imp .Ltop,.Lexit-16 };; | |
| 97 { .mmi; LDKEY yy=[key] // load key->y | |
| 98 add ksch=SZ,key | |
| 99 mov ar.lc=in1 } | |
| 100 { .mmi; mov key_y[1]=r0 // guarantee inequality | |
| 101 // in first iteration | |
| 102 add xx=1,xx | |
| 103 mov pr.rot=1<<16 };; | |
| 104 { .mii; nop.m 0 | |
| 105 dep key_x[1]=xx,r0,OFF,8 | |
| 106 mov ar.ec=3 };; // note that epilogue counter | |
| 107 // is off by 1. I compensate | |
| 108 // for this at exit... | |
| 109 .Ltop: | |
| 110 // The loop is scheduled for 4*(n+2) spin-rate on Itanium 2, which | |
| 111 // theoretically gives asymptotic performance of clock frequency | |
| 112 // divided by 4 bytes per seconds, or 400MBps on 1.6GHz CPU. This is | |
| 113 // for sizeof(RC4_INT)==4. For smaller RC4_INT STKEY inadvertently | |
| 114 // splits the last bundle and you end up with 5*n spin-rate:-( | |
| 115 // Originally the loop was scheduled for 3*n and relied on key | |
| 116 // schedule to be aligned at 256*sizeof(RC4_INT) boundary. But | |
| 117 // *(out++)=dat, which maps to st1, had same effect [inadvertent | |
| 118 // bundle split] and holded the loop back. Rescheduling for 4*n | |
| 119 // made it possible to eliminate dependence on specific alignment | |
| 120 // and allow OpenSSH keep "abusing" our API. Reaching for 3*n would | |
| 121 // require unrolling, sticking to variable shift instruction for | |
| 122 // collecting output [to avoid starvation for integer shifter] and | |
| 123 // copying of key schedule to controlled place in stack [so that | |
| 124 // deposit instruction can serve as substitute for whole | |
| 125 // key->data+((x&255)<<log2(sizeof(key->data[0])))]... | |
| 126 { .mmi; (p19) st1 [out]=dat[3],1 // *(out++)=dat | |
| 127 (p16) add xx=1,xx // x++ | |
| 128 (p18) dep rnd[1]=rnd[1],r0,OFF,8 } // ((tx+ty)&255)<<OFF | |
| 129 { .mmi; (p16) add key_x[1]=ksch,key_x[1] // &key[xx&255] | |
| 130 (p17) add key_y[1]=ksch,key_y[1] };; // &key[yy&255] | |
| 131 { .mmi; (p16) LDKEY tx[0]=[key_x[1]] // tx=key[xx] | |
| 132 (p17) LDKEY ty[0]=[key_y[1]] // ty=key[yy] | |
| 133 (p16) dep key_x[0]=xx,r0,OFF,8 } // (xx&255)<<OFF | |
| 134 { .mmi; (p18) add rnd[1]=ksch,rnd[1] // &key[(tx+ty)&255] | |
| 135 (p16) cmp.ne.unc p20,p21=key_x[1],key_y[1] };; | |
| 136 { .mmi; (p18) LDKEY rnd[1]=[rnd[1]] // rnd=key[(tx+ty)&255] | |
| 137 (p16) ld1 dat[0]=[inp],1 } // dat=*(inp++) | |
| 138 .pred.rel "mutex",p20,p21 | |
| 139 { .mmi; (p21) add yy=yy,tx[1] // (p16) | |
| 140 (p20) add yy=yy,tx[0] // (p16) y+=tx | |
| 141 (p21) mov tx[0]=tx[1] };; // (p16) | |
| 142 { .mmi; (p17) STKEY [key_y[1]]=tx[1] // key[yy]=tx | |
| 143 (p17) STKEY [key_x[2]]=ty[0] // key[xx]=ty | |
| 144 (p16) dep key_y[0]=yy,r0,OFF,8 } // &key[yy&255] | |
| 145 { .mmb; (p17) add rnd[0]=tx[1],ty[0] // tx+=ty | |
| 146 (p18) xor dat[2]=dat[2],rnd[1] // dat^=rnd | |
| 147 br.ctop.sptk .Ltop };; | |
| 148 .Lexit: | |
| 149 { .mib; STKEY [key]=yy,-SZ // save key->y | |
| 150 mov pr=prsave,0x1ffff | |
| 151 nop.b 0 } | |
| 152 { .mib; st1 [out]=dat[3],1 // compensate for truncated | |
| 153 // epilogue counter | |
| 154 add xx=-1,xx | |
| 155 nop.b 0 };; | |
| 156 { .mib; STKEY [key]=xx // save key->x | |
| 157 mov ar.lc=r3 | |
| 158 br.ret.sptk.many b0 };; | |
| 159 .endp RC4# | |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 9254031:
Upgrade chrome's OpenSSL to same version Android ships with. (Closed)
Base URL: http://src.chromium.org/svn/trunk/deps/third_party/openssl/