Conversion to UTF-8 where needed

[openssl.git] / crypto / aes / asm / aes-586.pl

diff --git a/crypto/aes/asm/aes-586.pl b/crypto/aes/asm/aes-586.pl
index 1c1e23e575996d5730f11d7620fa8f7cb976d2ff..767f2042623d0b5452edb0544760cc5deb3b0a2b 100755 (executable)
--- a/crypto/aes/asm/aes-586.pl
+++ b/crypto/aes/asm/aes-586.pl
@@ -45,7 +45,7 @@
 # the undertaken effort was that it appeared that in tight IA-32
 # register window little-endian flavor could achieve slightly higher
 # Instruction Level Parallelism, and it indeed resulted in up to 15%
-# better performance on most recent µ-archs...
+# better performance on most recent µ-archs...
 #
 # Third version adds AES_cbc_encrypt implementation, which resulted in
 # up to 40% performance imrovement of CBC benchmark results. 40% was
@@ -224,7 +224,7 @@ sub _data_word() { my $i; while(defined($i=shift)) { &data_word($i,$i); } }
 $speed_limit=512;      # chunks smaller than $speed_limit are
                        # processed with compact routine in CBC mode
 $small_footprint=1;    # $small_footprint=1 code is ~5% slower [on
-                       # recent µ-archs], but ~5 times smaller!
+                       # recent µ-archs], but ~5 times smaller!
                        # I favor compact code to minimize cache
                        # contention and in hope to "collect" 5% back
                        # in real-life applications...
@@ -565,7 +565,7 @@ sub enctransform()
 # Performance is not actually extraordinary in comparison to pure
 # x86 code. In particular encrypt performance is virtually the same.
 # Decrypt performance on the other hand is 15-20% better on newer
-# µ-archs [but we're thankful for *any* improvement here], and ~50%
+# µ-archs [but we're thankful for *any* improvement here], and ~50%
 # better on PIII:-) And additionally on the pros side this code
 # eliminates redundant references to stack and thus relieves/
 # minimizes the pressure on the memory bus.