Minor perlasm clean-up.

diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index d112cf2056fc36302a36b44257564c7c745890d0..b158f72971a1678be7dd3cb0f1f51ff76f100e7a 100755 (executable)
--- a/crypto/perlasm/x86_64-xlate.pl
+++ b/crypto/perlasm/x86_64-xlate.pl
@@ -488,8 +488,8 @@ close STDOUT;
 # as that 32 bytes from 8(%rsp) can always be used as temporal
 # storage [without allocating a frame]. One can actually argue that
 # one can assume a "red zone" above stack pointer under Win64 as well.
-# Point is that at apparently no accasion Windows would alter the area
-# above stack pointer in true asynchronous manner...
+# Point is that at apparently no occasion Windows kernel would alter
+# the area above user stack pointer in true asynchronous manner...
 #
 # All the above means that if assembler programmer adheres to Unix
 # register and stack layout, but disregards the "red zone" existense,

diff --git a/crypto/perlasm/x86ms.pl b/crypto/perlasm/x86ms.pl
index 83d9205e4746c4ce415bca10a4d6c05b8601b8b4..de5273ede76d2da3acb3e86601cf03fd303640ab 100644 (file)
--- a/crypto/perlasm/x86ms.pl
+++ b/crypto/perlasm/x86ms.pl
@@ -27,7 +27,6 @@ $label="L000";
 sub main'asm_init_output { @out=(); }
 sub main'asm_get_output { return(@out); }
 sub main'get_labels { return(@labels); }
-sub main'external_label { push(@labels,@_); }
 sub main'external_label
 {
        push(@labels,@_);