aboutsummaryrefslogtreecommitdiff
path: root/openssl/crypto/rc4/asm/rc4-ia64.S
diff options
context:
space:
mode:
authormarha <marha@users.sourceforge.net>2009-06-28 22:07:26 +0000
committermarha <marha@users.sourceforge.net>2009-06-28 22:07:26 +0000
commit3562e78743202e43aec8727005182a2558117eca (patch)
tree8f9113a77d12470c5c851a2a8e4cb02e89df7d43 /openssl/crypto/rc4/asm/rc4-ia64.S
downloadvcxsrv-3562e78743202e43aec8727005182a2558117eca.tar.gz
vcxsrv-3562e78743202e43aec8727005182a2558117eca.tar.bz2
vcxsrv-3562e78743202e43aec8727005182a2558117eca.zip
Checked in the following released items:
xkeyboard-config-1.4.tar.gz ttf-bitstream-vera-1.10.tar.gz font-alias-1.0.1.tar.gz font-sun-misc-1.0.0.tar.gz font-sun-misc-1.0.0.tar.gz font-sony-misc-1.0.0.tar.gz font-schumacher-misc-1.0.0.tar.gz font-mutt-misc-1.0.0.tar.gz font-misc-misc-1.0.0.tar.gz font-misc-meltho-1.0.0.tar.gz font-micro-misc-1.0.0.tar.gz font-jis-misc-1.0.0.tar.gz font-isas-misc-1.0.0.tar.gz font-dec-misc-1.0.0.tar.gz font-daewoo-misc-1.0.0.tar.gz font-cursor-misc-1.0.0.tar.gz font-arabic-misc-1.0.0.tar.gz font-winitzki-cyrillic-1.0.0.tar.gz font-misc-cyrillic-1.0.0.tar.gz font-cronyx-cyrillic-1.0.0.tar.gz font-screen-cyrillic-1.0.1.tar.gz font-xfree86-type1-1.0.1.tar.gz font-adobe-utopia-type1-1.0.1.tar.gz font-ibm-type1-1.0.0.tar.gz font-bitstream-type1-1.0.0.tar.gz font-bitstream-speedo-1.0.0.tar.gz font-bh-ttf-1.0.0.tar.gz font-bh-type1-1.0.0.tar.gz font-bitstream-100dpi-1.0.0.tar.gz font-bh-lucidatypewriter-100dpi-1.0.0.tar.gz font-bh-100dpi-1.0.0.tar.gz font-adobe-utopia-100dpi-1.0.1.tar.gz font-adobe-100dpi-1.0.0.tar.gz font-util-1.0.1.tar.gz font-bitstream-75dpi-1.0.0.tar.gz font-bh-lucidatypewriter-75dpi-1.0.0.tar.gz font-adobe-utopia-75dpi-1.0.1.tar.gz font-bh-75dpi-1.0.0.tar.gz bdftopcf-1.0.1.tar.gz font-adobe-75dpi-1.0.0.tar.gz mkfontscale-1.0.6.tar.gz openssl-0.9.8k.tar.gz bigreqsproto-1.0.2.tar.gz xtrans-1.2.2.tar.gz resourceproto-1.0.2.tar.gz inputproto-1.4.4.tar.gz compositeproto-0.4.tar.gz damageproto-1.1.0.tar.gz zlib-1.2.3.tar.gz xkbcomp-1.0.5.tar.gz freetype-2.3.9.tar.gz pthreads-w32-2-8-0-release.tar.gz pixman-0.12.0.tar.gz kbproto-1.0.3.tar.gz evieext-1.0.2.tar.gz fixesproto-4.0.tar.gz recordproto-1.13.2.tar.gz randrproto-1.2.2.tar.gz scrnsaverproto-1.1.0.tar.gz renderproto-0.9.3.tar.gz xcmiscproto-1.1.2.tar.gz fontsproto-2.0.2.tar.gz xextproto-7.0.3.tar.gz xproto-7.0.14.tar.gz libXdmcp-1.0.2.tar.gz libxkbfile-1.0.5.tar.gz libfontenc-1.0.4.tar.gz libXfont-1.3.4.tar.gz libX11-1.1.5.tar.gz libXau-1.0.4.tar.gz libxcb-1.1.tar.gz xorg-server-1.5.3.tar.gz
Diffstat (limited to 'openssl/crypto/rc4/asm/rc4-ia64.S')
-rw-r--r--openssl/crypto/rc4/asm/rc4-ia64.S159
1 files changed, 159 insertions, 0 deletions
diff --git a/openssl/crypto/rc4/asm/rc4-ia64.S b/openssl/crypto/rc4/asm/rc4-ia64.S
new file mode 100644
index 000000000..8210c47d0
--- /dev/null
+++ b/openssl/crypto/rc4/asm/rc4-ia64.S
@@ -0,0 +1,159 @@
+// ====================================================================
+// Written by Andy Polyakov <appro@fy.chalmers.se> for the OpenSSL
+// project.
+//
+// Rights for redistribution and usage in source and binary forms are
+// granted according to the OpenSSL license. Warranty of any kind is
+// disclaimed.
+// ====================================================================
+
+.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
+// C language, compiler doesn't [dare to] reorder load and stores. But
+// 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
+// least we can safely reorder references to key schedule in respect
+// to input and output streams. Secondly, from the first [close] glance
+// it appeared that it's possible to pull up some references to
+// elements of the key schedule itself. Original rationale ["prior
+// loads are not safe only for "degenerated" key schedule, when some
+// 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:-) 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
+
+#if defined(_HPUX_SOURCE) && !defined(_LP64)
+# define ADDP addp4
+#else
+# 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
+# define LDKEY ld1
+# define STKEY st1
+# define OFF 0
+#elif SZ==4 // RC4_INT is unsigned int
+# define LDKEY ld4
+# define STKEY st4
+# define OFF 2
+#elif SZ==8 // RC4_INT is unsigned long
+# define LDKEY ld8
+# define STKEY st8
+# define OFF 3
+#endif
+
+out=r8; // [expanded] output pointer
+inp=r9; // [expanded] output pointer
+prsave=r10;
+key=r28; // [expanded] pointer to RC4_KEY
+ksch=r29; // (key->data+255)[&~(sizeof(key->data)-1)]
+xx=r30;
+yy=r31;
+
+// void RC4(RC4_KEY *key,size_t len,const void *inp,void *out);
+.global RC4#
+.proc RC4#
+.align 32
+.skip 16
+RC4:
+ .prologue
+ .save ar.pfs,r2
+{ .mii; alloc r2=ar.pfs,4,12,0,16
+ .save pr,prsave
+ mov prsave=pr
+ ADDP key=0,in0 };;
+{ .mib; cmp.eq p6,p0=0,in1 // len==0?
+ .save ar.lc,r3
+ mov r3=ar.lc
+(p6) br.ret.spnt.many b0 };; // emergency exit
+
+ .body
+ .rotr dat[4],key_x[4],tx[2],rnd[2],key_y[2],ty[1];
+
+{ .mib; LDKEY xx=[key],SZ // load key->x
+ add in1=-1,in1 // adjust len for loop counter
+ nop.b 0 }
+{ .mib; ADDP inp=0,in2
+ ADDP out=0,in3
+ brp.loop.imp .Ltop,.Lexit-16 };;
+{ .mmi; LDKEY yy=[key] // load key->y
+ 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,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 4*(n+2) spin-rate on Itanium 2, which
+// theoretically gives asymptotic performance of clock frequency
+// 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++
+ (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++)
+.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,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 };;
+.Lexit:
+{ .mib; STKEY [key]=yy,-SZ // save key->y
+ mov pr=prsave,0x1ffff
+ nop.b 0 }
+{ .mib; st1 [out]=dat[3],1 // compensate for truncated
+ // epilogue counter
+ add xx=-1,xx
+ nop.b 0 };;
+{ .mib; STKEY [key]=xx // save key->x
+ mov ar.lc=r3
+ br.ret.sptk.many b0 };;
+.endp RC4#