summaryrefslogtreecommitdiffstats
path: root/crypto/perlasm
diff options
context:
space:
mode:
authorAndy Polyakov <appro@openssl.org>2005-11-06 11:59:39 +0000
committerAndy Polyakov <appro@openssl.org>2005-11-06 11:59:39 +0000
commitd256b95768ae01baba1915c802e2ba05c25348cc (patch)
tree34b9459f41e8943978f2be38ced8183921e01445 /crypto/perlasm
parentf5301388766a1e30a377cb131cfa5fba782bda0b (diff)
x86_64-xlate.pl commentary section update.
Diffstat (limited to 'crypto/perlasm')
-rwxr-xr-xcrypto/perlasm/x86_64-xlate.pl5
1 files changed, 4 insertions, 1 deletions
diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index 61dc4c2c3a..d112cf2056 100755
--- a/crypto/perlasm/x86_64-xlate.pl
+++ b/crypto/perlasm/x86_64-xlate.pl
@@ -486,7 +486,10 @@ close STDOUT;
# arguments passed to callee, *but* not less than 4! This means that
# upon function entry point 5th argument resides at 40(%rsp), as well
# as that 32 bytes from 8(%rsp) can always be used as temporal
-# storage [without allocating a frame].
+# 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...
#
# All the above means that if assembler programmer adheres to Unix
# register and stack layout, but disregards the "red zone" existense,