From 2eb7e5ff6bb69760f9dd4a43e7e3520ebb930120 Mon Sep 17 00:00:00 2001 From: jmc <> Date: Mon, 26 Dec 2022 07:18:53 +0000 Subject: spelling fixes; from paul tagliamonte i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb --- src/lib/libcrypto/sha/asm/sha1-586.pl | 8 ++++---- src/lib/libcrypto/sha/asm/sha1-sparcv9a.pl | 2 +- src/lib/libcrypto/sha/asm/sha1-thumb.pl | 2 +- src/lib/libcrypto/sha/asm/sha1-x86_64.pl | 4 ++-- src/lib/libcrypto/sha/asm/sha512-x86_64.pl | 2 +- 5 files changed, 9 insertions(+), 9 deletions(-) (limited to 'src/lib/libcrypto/sha') diff --git a/src/lib/libcrypto/sha/asm/sha1-586.pl b/src/lib/libcrypto/sha/asm/sha1-586.pl index d29ed84706..1de5e2650e 100644 --- a/src/lib/libcrypto/sha/asm/sha1-586.pl +++ b/src/lib/libcrypto/sha/asm/sha1-586.pl @@ -28,7 +28,7 @@ # P4 +85%(!) +45% # # As you can see Pentium came out as looser:-( Yet I reckoned that -# improvement on P4 outweights the loss and incorporate this +# improvement on P4 outweighs the loss and incorporate this # re-tuned code to 0.9.7 and later. # ---------------------------------------------------------------- # @@ -511,14 +511,14 @@ my $_ror=sub { &ror(@_) }; # # Temporary registers usage. X[2] is volatile at the entry and at the # end is restored from backtrace ring buffer. X[3] is expected to -# contain current K_XX_XX constant and is used to caclulate X[-1]+K +# contain current K_XX_XX constant and is used to calculate X[-1]+K # from previous round, it becomes volatile the moment the value is # saved to stack for transfer to IALU. X[4] becomes volatile whenever # X[-4] is accumulated and offloaded to backtrace ring buffer, at the # end it is loaded with next K_XX_XX [which becomes X[3] in next # round]... # -sub Xupdate_ssse3_16_31() # recall that $Xi starts wtih 4 +sub Xupdate_ssse3_16_31() # recall that $Xi starts with 4 { use integer; my $body = shift; my @insns = (&$body,&$body,&$body,&$body); # 40 instructions @@ -940,7 +940,7 @@ my $_ror=sub { &shrd(@_[0],@_) }; &vmovdqa(&QWP(0+32,"esp"),@X[2]); &jmp (&label("loop")); -sub Xupdate_avx_16_31() # recall that $Xi starts wtih 4 +sub Xupdate_avx_16_31() # recall that $Xi starts with 4 { use integer; my $body = shift; my @insns = (&$body,&$body,&$body,&$body); # 40 instructions diff --git a/src/lib/libcrypto/sha/asm/sha1-sparcv9a.pl b/src/lib/libcrypto/sha/asm/sha1-sparcv9a.pl index e65291bbd9..e81a4dcb05 100644 --- a/src/lib/libcrypto/sha/asm/sha1-sparcv9a.pl +++ b/src/lib/libcrypto/sha/asm/sha1-sparcv9a.pl @@ -544,7 +544,7 @@ ___ # Purpose of these subroutines is to explicitly encode VIS instructions, # so that one can compile the module without having to specify VIS -# extentions on compiler command line, e.g. -xarch=v9 vs. -xarch=v9a. +# extensions on compiler command line, e.g. -xarch=v9 vs. -xarch=v9a. # Idea is to reserve for option to produce "universal" binary and let # programmer detect if current CPU is VIS capable at run-time. sub unvis { diff --git a/src/lib/libcrypto/sha/asm/sha1-thumb.pl b/src/lib/libcrypto/sha/asm/sha1-thumb.pl index 7c9ea9b029..553e9cedb5 100644 --- a/src/lib/libcrypto/sha/asm/sha1-thumb.pl +++ b/src/lib/libcrypto/sha/asm/sha1-thumb.pl @@ -14,7 +14,7 @@ # The code does not present direct interest to OpenSSL, because of low # performance. Its purpose is to establish _size_ benchmark. Pretty # useless one I must say, because 30% or 88 bytes larger ARMv4 code -# [avialable on demand] is almost _twice_ as fast. It should also be +# [available on demand] is almost _twice_ as fast. It should also be # noted that in-lining of .Lcommon and .Lrotate improves performance # by over 40%, while code increases by only 10% or 32 bytes. But once # again, the goal was to establish _size_ benchmark, not performance. diff --git a/src/lib/libcrypto/sha/asm/sha1-x86_64.pl b/src/lib/libcrypto/sha/asm/sha1-x86_64.pl index 147d21570b..cc8ef5337d 100755 --- a/src/lib/libcrypto/sha/asm/sha1-x86_64.pl +++ b/src/lib/libcrypto/sha/asm/sha1-x86_64.pl @@ -368,7 +368,7 @@ sub AUTOLOAD() # thunk [simplified] 32-bit style perlasm $code .= "\t$opcode\t".join(',',$arg,reverse @_)."\n"; } -sub Xupdate_ssse3_16_31() # recall that $Xi starts wtih 4 +sub Xupdate_ssse3_16_31() # recall that $Xi starts with 4 { use integer; my $body = shift; my @insns = (&$body,&$body,&$body,&$body); # 40 instructions @@ -779,7 +779,7 @@ $code.=<<___; jmp .Loop_avx ___ -sub Xupdate_avx_16_31() # recall that $Xi starts wtih 4 +sub Xupdate_avx_16_31() # recall that $Xi starts with 4 { use integer; my $body = shift; my @insns = (&$body,&$body,&$body,&$body); # 40 instructions diff --git a/src/lib/libcrypto/sha/asm/sha512-x86_64.pl b/src/lib/libcrypto/sha/asm/sha512-x86_64.pl index feb0f9e776..bc4b2e7487 100755 --- a/src/lib/libcrypto/sha/asm/sha512-x86_64.pl +++ b/src/lib/libcrypto/sha/asm/sha512-x86_64.pl @@ -34,7 +34,7 @@ # level parallelism, on a given CPU implementation in this case. # # Special note on Intel EM64T. While Opteron CPU exhibits perfect -# perfromance ratio of 1.5 between 64- and 32-bit flavors [see above], +# performance ratio of 1.5 between 64- and 32-bit flavors [see above], # [currently available] EM64T CPUs apparently are far from it. On the # contrary, 64-bit version, sha512_block, is ~30% *slower* than 32-bit # sha256_block:-( This is presumably because 64-bit shifts/rotates -- cgit v1.2.3-55-g6feb