From 6a3a7f3076354a4c2414b16f7fa1b76d5e4174d2 Mon Sep 17 00:00:00 2001 From: Andy Polyakov Date: Wed, 9 Nov 2005 17:20:26 +0000 Subject: [PATCH] Minor perlasm clean-up. --- crypto/perlasm/x86_64-xlate.pl | 4 ++-- crypto/perlasm/x86ms.pl | 1 - 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,@_); -- 2.25.1