Home | History | Annotate | Download | only in asm
      1 // ====================================================================
      2 // Written by Andy Polyakov <appro (at) 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 (at) 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#
    160