generic-library/openssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix rc4-ia64.S to pass more exhaustive regression tests.

Browse Source
This commit is contained in:
Andy Polyakov 2004-12-02 10:07:55 +00:00
parent 8544a80776
commit f774accdbf
1 changed files with 24 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
crypto/rc4/asm/rc4-ia64.S
View File

@ -7,7 +7,7 @@
// disclaimed. // disclaimed.
// ==================================================================== // ====================================================================
.ident "rc4-ia64.S, Version 1.0" .ident "rc4-ia64.S, Version 1.1"
.ident "IA-64 ISA artwork by Andy Polyakov <appro@fy.chalmers.se>" .ident "IA-64 ISA artwork by Andy Polyakov <appro@fy.chalmers.se>"
// What's wrong with compiler generated code? Because of the nature of // What's wrong with compiler generated code? Because of the nature of
@ -15,11 +15,19 @@
// being memory-bound, RC4 should benefit from reorder [on in-order- // being memory-bound, RC4 should benefit from reorder [on in-order-
// execution core such as IA-64]. But what can we reorder? At the very // execution core such as IA-64]. But what can we reorder? At the very
// least we can safely reorder references to key schedule in respect // least we can safely reorder references to key schedule in respect
// to input and output streams. Secondly, less obvious, it's possible // to input and output streams. Secondly, from the first [close] glance
// to pull up some references to elements of the key schedule itself. // it appeared that it's possible to pull up some references to
// Fact is that such prior loads are not safe only for "degenerated" // elements of the key schedule itself. Original rationale ["prior
// key schedule, when some elements equal to the same value, which is // loads are not safe only for "degenerated" key schedule, when some
// never the case [key schedule setup routine makes sure it's not]. // elements equal to the same value"] was kind of sloppy. I should have
// formulated as it really was: if we assume that pulling up reference
// to key[x+1] is not safe, then it would mean that key schedule would
// "degenerate," which is never the case. The problem is that this
// holds true in respect to references to key[x], but not to key[y].
// Legitimate "collisions" do occur within every 256^2 bytes window.
// Fortunately there're enough free instruction slots to keep prior
// reference to key[x+1], detect "collision" and compensate for it.
// All this without sacrificing a single clock cycle:-)
// Furthermore. In order to compress loop body to the minimum, I chose // Furthermore. In order to compress loop body to the minimum, I chose
// to deploy deposit instruction, which substitutes for the whole // to deploy deposit instruction, which substitutes for the whole
// key->data+((x&255)<<log2(sizeof(key->data[0]))). This unfortunately // key->data+((x&255)<<log2(sizeof(key->data[0]))). This unfortunately
@ -97,7 +105,8 @@ RC4:
// deposit instruction only, // deposit instruction only,
// I don't have to &~255... // I don't have to &~255...
mov ar.lc=in1 } mov ar.lc=in1 }
{ .mmi; nop.m 0 { .mmi; mov key_y[1]=r0 // guarantee inequality
// in first iteration
add xx=1,xx add xx=1,xx
mov pr.rot=1<<16 };; mov pr.rot=1<<16 };;
{ .mii; nop.m 0 { .mii; nop.m 0
@ -111,23 +120,23 @@ RC4:
// divided by 3 bytes per seconds, or 500MBps on 1.5GHz CPU. Measured // divided by 3 bytes per seconds, or 500MBps on 1.5GHz CPU. Measured
// performance however is distinctly lower than 1/4:-( The culplrit // performance however is distinctly lower than 1/4:-( The culplrit
// seems to be *(out++)=dat, which inadvertently splits the bundle, // seems to be *(out++)=dat, which inadvertently splits the bundle,
// even though there is M-unit available... Unrolling is due... // even though there is M-port available... Unrolling is due...
// Unrolled loop should collect output with variable shift instruction // Unrolled loop should collect output with variable shift instruction
// in order to avoid starvation for integer shifter... Only output // in order to avoid starvation for integer shifter... It should be
// pointer has to be aligned... It should be possible to get pretty // possible to get pretty close to theoretical peak...
// close to theoretical peak...
{ .mmi; (p16) LDKEY tx[0]=[key_x[1]] // tx=key[xx] { .mmi; (p16) LDKEY tx[0]=[key_x[1]] // tx=key[xx]
(p17) LDKEY ty[0]=[key_y[1]] // ty=key[yy] (p17) LDKEY ty[0]=[key_y[1]] // ty=key[yy]
(p18) dep rnd[1]=rnd[1],ksch,OFF,8} // &key[(tx+ty)&255] (p18) dep rnd[1]=rnd[1],ksch,OFF,8} // &key[(tx+ty)&255]
{ .mmi; (p19) st1 [out]=dat[3],1 // *(out++)=dat { .mmi; (p19) st1 [out]=dat[3],1 // *(out++)=dat
(p16) add xx=1,xx // x++ (p16) add xx=1,xx // x++
(p0) nop.i 0 };; (p16) cmp.ne.unc p20,p21=key_x[1],key_y[1] };;
{ .mmi; (p18) LDKEY rnd[1]=[rnd[1]] // rnd=key[(tx+ty)&255] { .mmi; (p18) LDKEY rnd[1]=[rnd[1]] // rnd=key[(tx+ty)&255]
(p16) ld1 dat[0]=[inp],1 // dat=*(inp++) (p16) ld1 dat[0]=[inp],1 // dat=*(inp++)
(p16) dep key_x[0]=xx,ksch,OFF,8 } // &key[xx&255] (p16) dep key_x[0]=xx,ksch,OFF,8 } // &key[xx&255]
{ .mmi; (p0) nop.m 0 .pred.rel "mutex",p20,p21
(p16) add yy=yy,tx[0] // y+=tx { .mmi; (p21) add yy=yy,tx[1] // (p16)
(p0) nop.i 0 };; (p20) add yy=yy,tx[0] // (p16) y+=tx
(p21) mov tx[0]=tx[1] };; // (p16)
{ .mmi; (p17) STKEY [key_y[1]]=tx[1] // key[yy]=tx { .mmi; (p17) STKEY [key_y[1]]=tx[1] // key[yy]=tx
(p17) STKEY [key_x[2]]=ty[0] // key[xx]=ty (p17) STKEY [key_x[2]]=ty[0] // key[xx]=ty
(p16) dep key_y[0]=yy,ksch,OFF,8 } // &key[yy&255] (p16) dep key_y[0]=yy,ksch,OFF,8 } // &key[yy&255]