diff options
author | klemens <ka7@github.com> | 2016-08-05 19:56:58 +0200 |
---|---|---|
committer | Rich Salz <rsalz@openssl.org> | 2016-08-05 19:07:30 -0400 |
commit | 6025001707fd65679d758c877200469d4e72ea88 (patch) | |
tree | 557bc457aea10e4f854f1ae975d38b0e9c8c79fb /crypto/bn | |
parent | 1ccbe6b32c98f61526e364c7abc94f55ec600293 (diff) |
spelling fixes, just comments and readme.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1413)
Diffstat (limited to 'crypto/bn')
-rw-r--r-- | crypto/bn/asm/ia64.S | 6 | ||||
-rw-r--r-- | crypto/bn/asm/mips.pl | 2 | ||||
-rw-r--r-- | crypto/bn/asm/ppc.pl | 4 | ||||
-rw-r--r-- | crypto/bn/asm/sparcv8plus.S | 2 | ||||
-rw-r--r-- | crypto/bn/asm/sparcv9-mont.pl | 2 | ||||
-rwxr-xr-x | crypto/bn/asm/sparcv9a-mont.pl | 2 | ||||
-rwxr-xr-x | crypto/bn/asm/x86-mont.pl | 2 |
7 files changed, 10 insertions, 10 deletions
diff --git a/crypto/bn/asm/ia64.S b/crypto/bn/asm/ia64.S index 2fdf5bbabe..f2404a3c1e 100644 --- a/crypto/bn/asm/ia64.S +++ b/crypto/bn/asm/ia64.S @@ -29,7 +29,7 @@ // ports is the same, i.e. 2, while I need 4. In other words, to this // module Itanium2 remains effectively as "wide" as Itanium. Yet it's // essentially different in respect to this module, and a re-tune was -// required. Well, because some intruction latencies has changed. Most +// required. Well, because some instruction latencies has changed. Most // noticeably those intensively used: // // Itanium Itanium2 @@ -370,7 +370,7 @@ bn_mul_words: // The loop therefore spins at the latency of xma minus 1, or in other // words at 6*(n+4) ticks:-( Compare to the "production" loop above // that runs in 2*(n+11) where the low latency problem is worked around -// by moving the dependency to one-tick latent interger ALU. Note that +// by moving the dependency to one-tick latent integer ALU. Note that // "distance" between ldf8 and xma is not latency of ldf8, but the // *difference* between xma and ldf8 latencies. .L_bn_mul_words_ctop: @@ -432,7 +432,7 @@ bn_mul_add_words: // version was performing *all* additions in IALU and was starving // for those even on Itanium 2. In this version one addition is // moved to FPU and is folded with multiplication. This is at cost -// of propogating the result from previous call to this subroutine +// of propagating the result from previous call to this subroutine // to L2 cache... In other words negligible even for shorter keys. // *Overall* performance improvement [over previous version] varies // from 11 to 22 percent depending on key length. diff --git a/crypto/bn/asm/mips.pl b/crypto/bn/asm/mips.pl index e3a38bd140..420f01f3a4 100644 --- a/crypto/bn/asm/mips.pl +++ b/crypto/bn/asm/mips.pl @@ -22,7 +22,7 @@ # This is drop-in MIPS III/IV ISA replacement for crypto/bn/bn_asm.c. # # The module is designed to work with either of the "new" MIPS ABI(5), -# namely N32 or N64, offered by IRIX 6.x. It's not ment to work under +# namely N32 or N64, offered by IRIX 6.x. It's not meant to work under # IRIX 5.x not only because it doesn't support new ABIs but also # because 5.x kernels put R4x00 CPU into 32-bit mode and all those # 64-bit instructions (daddu, dmultu, etc.) found below gonna only diff --git a/crypto/bn/asm/ppc.pl b/crypto/bn/asm/ppc.pl index 346e01faf5..4ea534a1c7 100644 --- a/crypto/bn/asm/ppc.pl +++ b/crypto/bn/asm/ppc.pl @@ -425,7 +425,7 @@ $data=<<EOF; # r9,r10, r11 are the equivalents of c1,c2, c3. # # Possible optimization of loading all 8 longs of a into registers -# doesnt provide any speedup +# doesn't provide any speedup # xor r0,r0,r0 #set r0 = 0.Used in addze @@ -1015,7 +1015,7 @@ $data=<<EOF; $UMULL r8,r6,r7 $UMULH r9,r6,r7 addc r11,r11,r8 - addze r12,r9 # since we didnt set r12 to zero before. + addze r12,r9 # since we didn't set r12 to zero before. addze r10,r0 #mul_add_c(a[1],b[0],c2,c3,c1); $LD r6,`1*$BNSZ`(r4) diff --git a/crypto/bn/asm/sparcv8plus.S b/crypto/bn/asm/sparcv8plus.S index e77e67aa57..714a136675 100644 --- a/crypto/bn/asm/sparcv8plus.S +++ b/crypto/bn/asm/sparcv8plus.S @@ -52,7 +52,7 @@ * # cd ../.. * # make; make test * - * Q. V8plus achitecture? What kind of beast is that? + * Q. V8plus architecture? What kind of beast is that? * A. Well, it's rather a programming model than an architecture... * It's actually v9-compliant, i.e. *any* UltraSPARC, CPU under * special conditions, namely when kernel doesn't preserve upper diff --git a/crypto/bn/asm/sparcv9-mont.pl b/crypto/bn/asm/sparcv9-mont.pl index 771cd96141..c36ce36806 100644 --- a/crypto/bn/asm/sparcv9-mont.pl +++ b/crypto/bn/asm/sparcv9-mont.pl @@ -20,7 +20,7 @@ # for undertaken effort are multiple. First of all, UltraSPARC is not # the whole SPARCv9 universe and other VIS-free implementations deserve # optimized code as much. Secondly, newly introduced UltraSPARC T1, -# a.k.a. Niagara, has shared FPU and concurrent FPU-intensive pathes, +# a.k.a. Niagara, has shared FPU and concurrent FPU-intensive paths, # such as sparcv9a-mont, will simply sink it. Yes, T1 is equipped with # several integrated RSA/DSA accelerator circuits accessible through # kernel driver [only(*)], but having decent user-land software diff --git a/crypto/bn/asm/sparcv9a-mont.pl b/crypto/bn/asm/sparcv9a-mont.pl index 902c0d3ad2..50b690653f 100755 --- a/crypto/bn/asm/sparcv9a-mont.pl +++ b/crypto/bn/asm/sparcv9a-mont.pl @@ -58,7 +58,7 @@ # # Modulo-scheduled inner loops allow to interleave floating point and # integer instructions and minimize Read-After-Write penalties. This -# results in *further* 20-50% perfromance improvement [depending on +# results in *further* 20-50% performance improvement [depending on # key length, more for longer keys] on USI&II cores and 30-80% - on # USIII&IV. diff --git a/crypto/bn/asm/x86-mont.pl b/crypto/bn/asm/x86-mont.pl index 9994b0bf96..09296ec662 100755 --- a/crypto/bn/asm/x86-mont.pl +++ b/crypto/bn/asm/x86-mont.pl @@ -294,7 +294,7 @@ if (0) { &xor ("eax","eax"); # signal "not fast enough [yet]" &jmp (&label("just_leave")); # While the below code provides competitive performance for - # all key lengthes on modern Intel cores, it's still more + # all key lengths on modern Intel cores, it's still more # than 10% slower for 4096-bit key elsewhere:-( "Competitive" # means compared to the original integer-only assembler. # 512-bit RSA sign is better by ~40%, but that's about all |