x86_64-xlate.pl commentary section update.
[openssl.git] / crypto / perlasm / x86_64-xlate.pl
index 166dcec6ace325e14400cce681b30cca5a3d5f14..d112cf2056fc36302a36b44257564c7c745890d0 100755 (executable)
@@ -167,10 +167,12 @@ my $current_function;
        my $self = shift;
        my $sz = shift;
 
-       # silently convert all EAs to 64-bit, required for elder GNU
-       # assembler and results in more compact code
-       $self->{index} =~ s/^[er](.?[0-9xp])[d]?$/r\1/;
-       $self->{base}  =~ s/^[er](.?[0-9xp])[d]?$/r\1/;
+       # Silently convert all EAs to 64-bit. This is required for
+       # elder GNU assembler and results in more compact code,
+       # *but* most importantly AES module depends on this feature!
+       $self->{index} =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
+       $self->{base}  =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
+
        if (!$masm) {
            # Solaris /usr/ccs/bin/as can't handle multiplications
            # in $self->{label}
@@ -484,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,