|
|
|
|
@@ -7,7 +7,7 @@
|
|
|
|
|
// disclaimed.
|
|
|
|
|
// ====================================================================
|
|
|
|
|
|
|
|
|
|
.ident "rc4-ia64.S, Version 1.1"
|
|
|
|
|
.ident "rc4-ia64.S, Version 2.0"
|
|
|
|
|
.ident "IA-64 ISA artwork by Andy Polyakov <appro@fy.chalmers.se>"
|
|
|
|
|
|
|
|
|
|
// What's wrong with compiler generated code? Because of the nature of
|
|
|
|
|
@@ -27,17 +27,10 @@
|
|
|
|
|
// 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
|
|
|
|
|
// to deploy deposit instruction, which substitutes for the whole
|
|
|
|
|
// key->data+((x&255)<<log2(sizeof(key->data[0]))). This unfortunately
|
|
|
|
|
// requires key->data to be aligned at sizeof(key->data) boundary.
|
|
|
|
|
// This is why you'll find "RC4_INT pad[512-256-2];" addenum to RC4_KEY
|
|
|
|
|
// and "d=(RC4_INT *)(((size_t)(d+255))&~(sizeof(key->data)-1));" in
|
|
|
|
|
// rc4_skey.c [and rc4_enc.c, where it's retained for debugging
|
|
|
|
|
// purposes]. Throughput is ~210MBps on 900MHz CPU, which is is >3x
|
|
|
|
|
// faster than gcc generated code and +30% - if compared to HP-UX C.
|
|
|
|
|
// Unrolling loop below should give >30% on top of that...
|
|
|
|
|
// All this without sacrificing a single clock cycle:-) Throughput is
|
|
|
|
|
// ~210MBps on 900MHz CPU, which is is >3x faster than gcc generated
|
|
|
|
|
// code and +30% - if compared to HP-UX C. Unrolling loop below should
|
|
|
|
|
// give >30% on top of that...
|
|
|
|
|
|
|
|
|
|
.text
|
|
|
|
|
.explicit
|
|
|
|
|
@@ -48,7 +41,9 @@
|
|
|
|
|
# define ADDP add
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef SZ
|
|
|
|
|
#define SZ 4 // this is set to sizeof(RC4_INT)
|
|
|
|
|
#endif
|
|
|
|
|
// SZ==4 seems to be optimal. At least SZ==8 is not any faster, not for
|
|
|
|
|
// assembler implementation, while SZ==1 code is ~30% slower.
|
|
|
|
|
#if SZ==1 // RC4_INT is unsigned char
|
|
|
|
|
@@ -101,45 +96,53 @@ RC4:
|
|
|
|
|
ADDP out=0,in3
|
|
|
|
|
brp.loop.imp .Ltop,.Lexit-16 };;
|
|
|
|
|
{ .mmi; LDKEY yy=[key] // load key->y
|
|
|
|
|
add ksch=(255+1)*SZ,key // as ksch will be used with
|
|
|
|
|
// deposit instruction only,
|
|
|
|
|
// I don't have to &~255...
|
|
|
|
|
add ksch=SZ,key
|
|
|
|
|
mov ar.lc=in1 }
|
|
|
|
|
{ .mmi; mov key_y[1]=r0 // guarantee inequality
|
|
|
|
|
// in first iteration
|
|
|
|
|
add xx=1,xx
|
|
|
|
|
mov pr.rot=1<<16 };;
|
|
|
|
|
{ .mii; nop.m 0
|
|
|
|
|
dep key_x[1]=xx,ksch,OFF,8
|
|
|
|
|
dep key_x[1]=xx,r0,OFF,8
|
|
|
|
|
mov ar.ec=3 };; // note that epilogue counter
|
|
|
|
|
// is off by 1. I compensate
|
|
|
|
|
// for this at exit...
|
|
|
|
|
.Ltop:
|
|
|
|
|
// The loop is scheduled for 3*(n+2) spin-rate on Itanium 2, which
|
|
|
|
|
// The loop is scheduled for 4*(n+2) spin-rate on Itanium 2, which
|
|
|
|
|
// theoretically gives asymptotic performance of clock frequency
|
|
|
|
|
// divided by 3 bytes per seconds, or 500MBps on 1.5GHz CPU. Measured
|
|
|
|
|
// performance however is distinctly lower than 1/4:-( The culplrit
|
|
|
|
|
// seems to be *(out++)=dat, which inadvertently splits the bundle,
|
|
|
|
|
// even though there is M-port available... Unrolling is due...
|
|
|
|
|
// Unrolled loop should collect output with variable shift instruction
|
|
|
|
|
// in order to avoid starvation for integer shifter... It should be
|
|
|
|
|
// possible to get pretty close to theoretical peak...
|
|
|
|
|
{ .mmi; (p16) LDKEY tx[0]=[key_x[1]] // tx=key[xx]
|
|
|
|
|
(p17) LDKEY ty[0]=[key_y[1]] // ty=key[yy]
|
|
|
|
|
(p18) dep rnd[1]=rnd[1],ksch,OFF,8} // &key[(tx+ty)&255]
|
|
|
|
|
// divided by 4 bytes per seconds, or 400MBps on 1.6GHz CPU. This is
|
|
|
|
|
// for sizeof(RC4_INT)==4. For smaller RC4_INT STKEY inadvertently
|
|
|
|
|
// splits the last bundle and you end up with 5*n spin-rate:-(
|
|
|
|
|
// Originally the loop was scheduled for 3*n and relied on key
|
|
|
|
|
// schedule to be aligned at 256*sizeof(RC4_INT) boundary. But
|
|
|
|
|
// *(out++)=dat, which maps to st1, had same effect [inadvertent
|
|
|
|
|
// bundle split] and holded the loop back. Rescheduling for 4*n
|
|
|
|
|
// made it possible to eliminate dependence on specific alignment
|
|
|
|
|
// and allow OpenSSH keep "abusing" our API. Reaching for 3*n would
|
|
|
|
|
// require unrolling, sticking to variable shift instruction for
|
|
|
|
|
// collecting output [to avoid starvation for integer shifter] and
|
|
|
|
|
// copying of key schedule to controlled place in stack [so that
|
|
|
|
|
// deposit instruction can serve as substitute for whole
|
|
|
|
|
// key->data+((x&255)<<log2(sizeof(key->data[0])))]...
|
|
|
|
|
{ .mmi; (p19) st1 [out]=dat[3],1 // *(out++)=dat
|
|
|
|
|
(p16) add xx=1,xx // x++
|
|
|
|
|
(p16) cmp.ne.unc p20,p21=key_x[1],key_y[1] };;
|
|
|
|
|
(p18) dep rnd[1]=rnd[1],r0,OFF,8 } // ((tx+ty)&255)<<OFF
|
|
|
|
|
{ .mmi; (p16) add key_x[1]=ksch,key_x[1] // &key[xx&255]
|
|
|
|
|
(p17) add key_y[1]=ksch,key_y[1] };; // &key[yy&255]
|
|
|
|
|
{ .mmi; (p16) LDKEY tx[0]=[key_x[1]] // tx=key[xx]
|
|
|
|
|
(p17) LDKEY ty[0]=[key_y[1]] // ty=key[yy]
|
|
|
|
|
(p16) dep key_x[0]=xx,r0,OFF,8 } // (xx&255)<<OFF
|
|
|
|
|
{ .mmi; (p18) add rnd[1]=ksch,rnd[1] // &key[(tx+ty)&255]
|
|
|
|
|
(p16) cmp.ne.unc p20,p21=key_x[1],key_y[1] };;
|
|
|
|
|
{ .mmi; (p18) LDKEY rnd[1]=[rnd[1]] // rnd=key[(tx+ty)&255]
|
|
|
|
|
(p16) ld1 dat[0]=[inp],1 // dat=*(inp++)
|
|
|
|
|
(p16) dep key_x[0]=xx,ksch,OFF,8 } // &key[xx&255]
|
|
|
|
|
(p16) ld1 dat[0]=[inp],1 } // dat=*(inp++)
|
|
|
|
|
.pred.rel "mutex",p20,p21
|
|
|
|
|
{ .mmi; (p21) add yy=yy,tx[1] // (p16)
|
|
|
|
|
(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
|
|
|
|
|
(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,r0,OFF,8 } // &key[yy&255]
|
|
|
|
|
{ .mmb; (p17) add rnd[0]=tx[1],ty[0] // tx+=ty
|
|
|
|
|
(p18) xor dat[2]=dat[2],rnd[1] // dat^=rnd
|
|
|
|
|
br.ctop.sptk .Ltop };;
|
|
|
|
|
|
Andy Polyakov