summaryrefslogtreecommitdiffstats
path: root/crypto
diff options
context:
space:
mode:
authorAndy Polyakov <appro@openssl.org>2005-11-09 17:20:26 +0000
committerAndy Polyakov <appro@openssl.org>2005-11-09 17:20:26 +0000
commit6a3a7f3076354a4c2414b16f7fa1b76d5e4174d2 (patch)
tree050a10cd3a28762a96f9062a54529b8e7ba1ea3c /crypto
parent63d3a9c5ea2a4a0b39d2e599333aa93df63b45fa (diff)
Minor perlasm clean-up.
Diffstat (limited to 'crypto')
-rwxr-xr-xcrypto/perlasm/x86_64-xlate.pl4
-rw-r--r--crypto/perlasm/x86ms.pl1
2 files changed, 2 insertions, 3 deletions
diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index d112cf2056..b158f72971 100755
--- 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 83d9205e47..de5273ede7 100644
--- 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,@_);