Du kannst nicht mehr als 25 Themen auswählen Themen müssen entweder mit einem Buchstaben oder einer Ziffer beginnen. Sie können Bindestriche („-“) enthalten und bis zu 35 Zeichen lang sein.

x86_64-xlate.pl 44 KiB

Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
Rebase x86_64-xlate.pl atop master. This functionally pulls in a number of changes from upstream, including: 4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1 1eb12c437bbeb2c748291bcd23733d4a59d5d1ca 6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b c25278db8e4c21772a0cd81f7873e767cbc6d219 e0a651945cb5a70a2abd9902c0fd3e9759d35867 d405aa2ff265965c71ce7331cf0e49d634a06924 ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e 9ba96fbb2523cb12747c559c704c58bd8f9e7982 Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'. To avoid having to deal with complex conflicts, this was done by taking a diff of our copy of the file with the point just before c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting parts of our diff on top of upstream's current version. Confirmed with generate_build_files.py that this makes no changes *except* d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout chacha-x86_64.pl's nasm output: @@ -1179,7 +1179,7 @@ $L$oop8x: vpslld ymm14,ymm0,12 vpsrld ymm0,ymm0,20 vpor ymm0,ymm14,ymm0 - vbroadcasti128 ymm14,YMMWORD[r11] + vbroadcasti128 ymm14,XMMWORD[r11] vpaddd ymm13,ymm13,ymm5 vpxor ymm1,ymm13,ymm1 vpslld ymm15,ymm1,12 This appears to be correct. vbroadcasti128 takes a 128-bit-wide second argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care. (Looking at a diff-diff may be a more useful way to review this CL.) Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d Reviewed-on: https://boringssl-review.googlesource.com/8392 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
vor 8 Jahren
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446
  1. #! /usr/bin/env perl
  2. # Copyright 2005-2016 The OpenSSL Project Authors. All Rights Reserved.
  3. #
  4. # Licensed under the OpenSSL license (the "License"). You may not use
  5. # this file except in compliance with the License. You can obtain a copy
  6. # in the file LICENSE in the source distribution or at
  7. # https://www.openssl.org/source/license.html
  8. # Ascetic x86_64 AT&T to MASM/NASM assembler translator by <appro>.
  9. #
  10. # Why AT&T to MASM and not vice versa? Several reasons. Because AT&T
  11. # format is way easier to parse. Because it's simpler to "gear" from
  12. # Unix ABI to Windows one [see cross-reference "card" at the end of
  13. # file]. Because Linux targets were available first...
  14. #
  15. # In addition the script also "distills" code suitable for GNU
  16. # assembler, so that it can be compiled with more rigid assemblers,
  17. # such as Solaris /usr/ccs/bin/as.
  18. #
  19. # This translator is not designed to convert *arbitrary* assembler
  20. # code from AT&T format to MASM one. It's designed to convert just
  21. # enough to provide for dual-ABI OpenSSL modules development...
  22. # There *are* limitations and you might have to modify your assembler
  23. # code or this script to achieve the desired result...
  24. #
  25. # Currently recognized limitations:
  26. #
  27. # - can't use multiple ops per line;
  28. #
  29. # Dual-ABI styling rules.
  30. #
  31. # 1. Adhere to Unix register and stack layout [see cross-reference
  32. # ABI "card" at the end for explanation].
  33. # 2. Forget about "red zone," stick to more traditional blended
  34. # stack frame allocation. If volatile storage is actually required
  35. # that is. If not, just leave the stack as is.
  36. # 3. Functions tagged with ".type name,@function" get crafted with
  37. # unified Win64 prologue and epilogue automatically. If you want
  38. # to take care of ABI differences yourself, tag functions as
  39. # ".type name,@abi-omnipotent" instead.
  40. # 4. To optimize the Win64 prologue you can specify number of input
  41. # arguments as ".type name,@function,N." Keep in mind that if N is
  42. # larger than 6, then you *have to* write "abi-omnipotent" code,
  43. # because >6 cases can't be addressed with unified prologue.
  44. # 5. Name local labels as .L*, do *not* use dynamic labels such as 1:
  45. # (sorry about latter).
  46. # 6. Don't use [or hand-code with .byte] "rep ret." "ret" mnemonic is
  47. # required to identify the spots, where to inject Win64 epilogue!
  48. # But on the pros, it's then prefixed with rep automatically:-)
  49. # 7. Stick to explicit ip-relative addressing. If you have to use
  50. # GOTPCREL addressing, stick to mov symbol@GOTPCREL(%rip),%r??.
  51. # Both are recognized and translated to proper Win64 addressing
  52. # modes.
  53. #
  54. # 8. In order to provide for structured exception handling unified
  55. # Win64 prologue copies %rsp value to %rax. For further details
  56. # see SEH paragraph at the end.
  57. # 9. .init segment is allowed to contain calls to functions only.
  58. # a. If function accepts more than 4 arguments *and* >4th argument
  59. # is declared as non 64-bit value, do clear its upper part.
  60. use strict;
  61. my $flavour = shift;
  62. my $output = shift;
  63. if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
  64. open STDOUT,">$output" || die "can't open $output: $!"
  65. if (defined($output));
  66. my $gas=1; $gas=0 if ($output =~ /\.asm$/);
  67. my $elf=1; $elf=0 if (!$gas);
  68. my $win64=0;
  69. my $prefix="";
  70. my $decor=".L";
  71. my $masmref=8 + 50727*2**-32; # 8.00.50727 shipped with VS2005
  72. my $masm=0;
  73. my $PTR=" PTR";
  74. my $nasmref=2.03;
  75. my $nasm=0;
  76. if ($flavour eq "mingw64") { $gas=1; $elf=0; $win64=1;
  77. # TODO(davidben): Before supporting the
  78. # mingw64 perlasm flavour, do away with this
  79. # environment variable check.
  80. die "mingw64 not supported";
  81. $prefix=`echo __USER_LABEL_PREFIX__ | $ENV{CC} -E -P -`;
  82. $prefix =~ s|\R$||; # Better chomp
  83. }
  84. elsif ($flavour eq "macosx") { $gas=1; $elf=0; $prefix="_"; $decor="L\$"; }
  85. elsif ($flavour eq "masm") { $gas=0; $elf=0; $masm=$masmref; $win64=1; $decor="\$L\$"; }
  86. elsif ($flavour eq "nasm") { $gas=0; $elf=0; $nasm=$nasmref; $win64=1; $decor="\$L\$"; $PTR=""; }
  87. elsif (!$gas) { die "unknown flavour $flavour"; }
  88. my $current_segment;
  89. my $current_function;
  90. my %globals;
  91. { package opcode; # pick up opcodes
  92. sub re {
  93. my ($class, $line) = @_;
  94. my $self = {};
  95. my $ret;
  96. if ($$line =~ /^([a-z][a-z0-9]*)/i) {
  97. bless $self,$class;
  98. $self->{op} = $1;
  99. $ret = $self;
  100. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  101. undef $self->{sz};
  102. if ($self->{op} =~ /^(movz)x?([bw]).*/) { # movz is pain...
  103. $self->{op} = $1;
  104. $self->{sz} = $2;
  105. } elsif ($self->{op} =~ /call|jmp/) {
  106. $self->{sz} = "";
  107. } elsif ($self->{op} =~ /^p/ && $' !~ /^(ush|op|insrw)/) { # SSEn
  108. $self->{sz} = "";
  109. } elsif ($self->{op} =~ /^[vk]/) { # VEX or k* such as kmov
  110. $self->{sz} = "";
  111. } elsif ($self->{op} =~ /mov[dq]/ && $$line =~ /%xmm/) {
  112. $self->{sz} = "";
  113. } elsif ($self->{op} =~ /([a-z]{3,})([qlwb])$/) {
  114. $self->{op} = $1;
  115. $self->{sz} = $2;
  116. }
  117. }
  118. $ret;
  119. }
  120. sub size {
  121. my ($self, $sz) = @_;
  122. $self->{sz} = $sz if (defined($sz) && !defined($self->{sz}));
  123. $self->{sz};
  124. }
  125. sub out {
  126. my $self = shift;
  127. if ($gas) {
  128. if ($self->{op} eq "movz") { # movz is pain...
  129. sprintf "%s%s%s",$self->{op},$self->{sz},shift;
  130. } elsif ($self->{op} =~ /^set/) {
  131. "$self->{op}";
  132. } elsif ($self->{op} eq "ret") {
  133. my $epilogue = "";
  134. if ($win64 && $current_function->{abi} eq "svr4") {
  135. $epilogue = "movq 8(%rsp),%rdi\n\t" .
  136. "movq 16(%rsp),%rsi\n\t";
  137. }
  138. $epilogue . ".byte 0xf3,0xc3";
  139. } elsif ($self->{op} eq "call" && !$elf && $current_segment eq ".init") {
  140. ".p2align\t3\n\t.quad";
  141. } else {
  142. "$self->{op}$self->{sz}";
  143. }
  144. } else {
  145. $self->{op} =~ s/^movz/movzx/;
  146. if ($self->{op} eq "ret") {
  147. $self->{op} = "";
  148. if ($win64 && $current_function->{abi} eq "svr4") {
  149. $self->{op} = "mov rdi,QWORD$PTR\[8+rsp\]\t;WIN64 epilogue\n\t".
  150. "mov rsi,QWORD$PTR\[16+rsp\]\n\t";
  151. }
  152. $self->{op} .= "DB\t0F3h,0C3h\t\t;repret";
  153. } elsif ($self->{op} =~ /^(pop|push)f/) {
  154. $self->{op} .= $self->{sz};
  155. } elsif ($self->{op} eq "call" && $current_segment eq ".CRT\$XCU") {
  156. $self->{op} = "\tDQ";
  157. }
  158. $self->{op};
  159. }
  160. }
  161. sub mnemonic {
  162. my ($self, $op) = @_;
  163. $self->{op}=$op if (defined($op));
  164. $self->{op};
  165. }
  166. }
  167. { package const; # pick up constants, which start with $
  168. sub re {
  169. my ($class, $line) = @_;
  170. my $self = {};
  171. my $ret;
  172. if ($$line =~ /^\$([^,]+)/) {
  173. bless $self, $class;
  174. $self->{value} = $1;
  175. $ret = $self;
  176. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  177. }
  178. $ret;
  179. }
  180. sub out {
  181. my $self = shift;
  182. $self->{value} =~ s/\b(0b[0-1]+)/oct($1)/eig;
  183. if ($gas) {
  184. # Solaris /usr/ccs/bin/as can't handle multiplications
  185. # in $self->{value}
  186. my $value = $self->{value};
  187. no warnings; # oct might complain about overflow, ignore here...
  188. $value =~ s/(?<![\w\$\.])(0x?[0-9a-f]+)/oct($1)/egi;
  189. if ($value =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg) {
  190. $self->{value} = $value;
  191. }
  192. sprintf "\$%s",$self->{value};
  193. } else {
  194. $self->{value} =~ s/0x([0-9a-f]+)/0$1h/ig if ($masm);
  195. sprintf "%s",$self->{value};
  196. }
  197. }
  198. }
  199. { package ea; # pick up effective addresses: expr(%reg,%reg,scale)
  200. my %szmap = ( b=>"BYTE$PTR", w=>"WORD$PTR",
  201. l=>"DWORD$PTR", d=>"DWORD$PTR",
  202. q=>"QWORD$PTR", o=>"OWORD$PTR",
  203. x=>"XMMWORD$PTR", y=>"YMMWORD$PTR",
  204. z=>"ZMMWORD$PTR" ) if (!$gas);
  205. sub re {
  206. my ($class, $line, $opcode) = @_;
  207. my $self = {};
  208. my $ret;
  209. # optional * ----vvv--- appears in indirect jmp/call
  210. if ($$line =~ /^(\*?)([^\(,]*)\(([%\w,]+)\)((?:{[^}]+})*)/) {
  211. bless $self, $class;
  212. $self->{asterisk} = $1;
  213. $self->{label} = $2;
  214. ($self->{base},$self->{index},$self->{scale})=split(/,/,$3);
  215. $self->{scale} = 1 if (!defined($self->{scale}));
  216. $self->{opmask} = $4;
  217. $ret = $self;
  218. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  219. if ($win64 && $self->{label} =~ s/\@GOTPCREL//) {
  220. die if ($opcode->mnemonic() ne "mov");
  221. $opcode->mnemonic("lea");
  222. }
  223. $self->{base} =~ s/^%//;
  224. $self->{index} =~ s/^%// if (defined($self->{index}));
  225. $self->{opcode} = $opcode;
  226. }
  227. $ret;
  228. }
  229. sub size {}
  230. sub out {
  231. my ($self, $sz) = @_;
  232. $self->{label} =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
  233. $self->{label} =~ s/\.L/$decor/g;
  234. # Silently convert all EAs to 64-bit. This is required for
  235. # elder GNU assembler and results in more compact code,
  236. # *but* most importantly AES module depends on this feature!
  237. $self->{index} =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
  238. $self->{base} =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
  239. # Solaris /usr/ccs/bin/as can't handle multiplications
  240. # in $self->{label}...
  241. use integer;
  242. $self->{label} =~ s/(?<![\w\$\.])(0x?[0-9a-f]+)/oct($1)/egi;
  243. $self->{label} =~ s/\b([0-9]+\s*[\*\/\%]\s*[0-9]+)\b/eval($1)/eg;
  244. # Some assemblers insist on signed presentation of 32-bit
  245. # offsets, but sign extension is a tricky business in perl...
  246. if ((1<<31)<<1) {
  247. $self->{label} =~ s/\b([0-9]+)\b/$1<<32>>32/eg;
  248. } else {
  249. $self->{label} =~ s/\b([0-9]+)\b/$1>>0/eg;
  250. }
  251. # if base register is %rbp or %r13, see if it's possible to
  252. # flip base and index registers [for better performance]
  253. if (!$self->{label} && $self->{index} && $self->{scale}==1 &&
  254. $self->{base} =~ /(rbp|r13)/) {
  255. $self->{base} = $self->{index}; $self->{index} = $1;
  256. }
  257. if ($gas) {
  258. $self->{label} =~ s/^___imp_/__imp__/ if ($flavour eq "mingw64");
  259. if (defined($self->{index})) {
  260. sprintf "%s%s(%s,%%%s,%d)%s",
  261. $self->{asterisk},$self->{label},
  262. $self->{base}?"%$self->{base}":"",
  263. $self->{index},$self->{scale},
  264. $self->{opmask};
  265. } else {
  266. sprintf "%s%s(%%%s)%s", $self->{asterisk},$self->{label},
  267. $self->{base},$self->{opmask};
  268. }
  269. } else {
  270. $self->{label} =~ s/\./\$/g;
  271. $self->{label} =~ s/(?<![\w\$\.])0x([0-9a-f]+)/0$1h/ig;
  272. $self->{label} = "($self->{label})" if ($self->{label} =~ /[\*\+\-\/]/);
  273. my $mnemonic = $self->{opcode}->mnemonic();
  274. ($self->{asterisk}) && ($sz="q") ||
  275. ($mnemonic =~ /^v?mov([qd])$/) && ($sz=$1) ||
  276. ($mnemonic =~ /^v?pinsr([qdwb])$/) && ($sz=$1) ||
  277. ($mnemonic =~ /^vpbroadcast([qdwb])$/) && ($sz=$1) ||
  278. ($mnemonic =~ /^v(?!perm)[a-z]+[fi]128$/) && ($sz="x");
  279. $self->{opmask} =~ s/%(k[0-7])/$1/;
  280. if (defined($self->{index})) {
  281. sprintf "%s[%s%s*%d%s]%s",$szmap{$sz},
  282. $self->{label}?"$self->{label}+":"",
  283. $self->{index},$self->{scale},
  284. $self->{base}?"+$self->{base}":"",
  285. $self->{opmask};
  286. } elsif ($self->{base} eq "rip") {
  287. sprintf "%s[%s]",$szmap{$sz},$self->{label};
  288. } else {
  289. sprintf "%s[%s%s]%s", $szmap{$sz},
  290. $self->{label}?"$self->{label}+":"",
  291. $self->{base},$self->{opmask};
  292. }
  293. }
  294. }
  295. }
  296. { package register; # pick up registers, which start with %.
  297. sub re {
  298. my ($class, $line, $opcode) = @_;
  299. my $self = {};
  300. my $ret;
  301. # optional * ----vvv--- appears in indirect jmp/call
  302. if ($$line =~ /^(\*?)%(\w+)((?:{[^}]+})*)/) {
  303. bless $self,$class;
  304. $self->{asterisk} = $1;
  305. $self->{value} = $2;
  306. $self->{opmask} = $3;
  307. $opcode->size($self->size());
  308. $ret = $self;
  309. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  310. }
  311. $ret;
  312. }
  313. sub size {
  314. my $self = shift;
  315. my $ret;
  316. if ($self->{value} =~ /^r[\d]+b$/i) { $ret="b"; }
  317. elsif ($self->{value} =~ /^r[\d]+w$/i) { $ret="w"; }
  318. elsif ($self->{value} =~ /^r[\d]+d$/i) { $ret="l"; }
  319. elsif ($self->{value} =~ /^r[\w]+$/i) { $ret="q"; }
  320. elsif ($self->{value} =~ /^[a-d][hl]$/i){ $ret="b"; }
  321. elsif ($self->{value} =~ /^[\w]{2}l$/i) { $ret="b"; }
  322. elsif ($self->{value} =~ /^[\w]{2}$/i) { $ret="w"; }
  323. elsif ($self->{value} =~ /^e[a-z]{2}$/i){ $ret="l"; }
  324. $ret;
  325. }
  326. sub out {
  327. my $self = shift;
  328. if ($gas) { sprintf "%s%%%s%s", $self->{asterisk},
  329. $self->{value},
  330. $self->{opmask}; }
  331. else { $self->{opmask} =~ s/%(k[0-7])/$1/;
  332. $self->{value}.$self->{opmask}; }
  333. }
  334. }
  335. { package label; # pick up labels, which end with :
  336. sub re {
  337. my ($class, $line) = @_;
  338. my $self = {};
  339. my $ret;
  340. if ($$line =~ /(^[\.\w]+)\:/) {
  341. bless $self,$class;
  342. $self->{value} = $1;
  343. $ret = $self;
  344. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  345. $self->{value} =~ s/^\.L/$decor/;
  346. }
  347. $ret;
  348. }
  349. sub out {
  350. my $self = shift;
  351. if ($gas) {
  352. my $func = ($globals{$self->{value}} or $self->{value}) . ":";
  353. if ($win64 && $current_function->{name} eq $self->{value}
  354. && $current_function->{abi} eq "svr4") {
  355. $func .= "\n";
  356. $func .= " movq %rdi,8(%rsp)\n";
  357. $func .= " movq %rsi,16(%rsp)\n";
  358. $func .= " movq %rsp,%rax\n";
  359. $func .= "${decor}SEH_begin_$current_function->{name}:\n";
  360. my $narg = $current_function->{narg};
  361. $narg=6 if (!defined($narg));
  362. $func .= " movq %rcx,%rdi\n" if ($narg>0);
  363. $func .= " movq %rdx,%rsi\n" if ($narg>1);
  364. $func .= " movq %r8,%rdx\n" if ($narg>2);
  365. $func .= " movq %r9,%rcx\n" if ($narg>3);
  366. $func .= " movq 40(%rsp),%r8\n" if ($narg>4);
  367. $func .= " movq 48(%rsp),%r9\n" if ($narg>5);
  368. }
  369. $func;
  370. } elsif ($self->{value} ne "$current_function->{name}") {
  371. # Make all labels in masm global.
  372. $self->{value} .= ":" if ($masm);
  373. $self->{value} . ":";
  374. } elsif ($win64 && $current_function->{abi} eq "svr4") {
  375. my $func = "$current_function->{name}" .
  376. ($nasm ? ":" : "\tPROC $current_function->{scope}") .
  377. "\n";
  378. $func .= " mov QWORD$PTR\[8+rsp\],rdi\t;WIN64 prologue\n";
  379. $func .= " mov QWORD$PTR\[16+rsp\],rsi\n";
  380. $func .= " mov rax,rsp\n";
  381. $func .= "${decor}SEH_begin_$current_function->{name}:";
  382. $func .= ":" if ($masm);
  383. $func .= "\n";
  384. my $narg = $current_function->{narg};
  385. $narg=6 if (!defined($narg));
  386. $func .= " mov rdi,rcx\n" if ($narg>0);
  387. $func .= " mov rsi,rdx\n" if ($narg>1);
  388. $func .= " mov rdx,r8\n" if ($narg>2);
  389. $func .= " mov rcx,r9\n" if ($narg>3);
  390. $func .= " mov r8,QWORD$PTR\[40+rsp\]\n" if ($narg>4);
  391. $func .= " mov r9,QWORD$PTR\[48+rsp\]\n" if ($narg>5);
  392. $func .= "\n";
  393. } else {
  394. "$current_function->{name}".
  395. ($nasm ? ":" : "\tPROC $current_function->{scope}");
  396. }
  397. }
  398. }
  399. { package expr; # pick up expressions
  400. sub re {
  401. my ($class, $line, $opcode) = @_;
  402. my $self = {};
  403. my $ret;
  404. if ($$line =~ /(^[^,]+)/) {
  405. bless $self,$class;
  406. $self->{value} = $1;
  407. $ret = $self;
  408. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  409. $self->{value} =~ s/\@PLT// if (!$elf);
  410. $self->{value} =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
  411. $self->{value} =~ s/\.L/$decor/g;
  412. $self->{opcode} = $opcode;
  413. }
  414. $ret;
  415. }
  416. sub out {
  417. my $self = shift;
  418. if ($nasm && $self->{opcode}->mnemonic()=~m/^j(?![re]cxz)/) {
  419. "NEAR ".$self->{value};
  420. } else {
  421. $self->{value};
  422. }
  423. }
  424. }
  425. { package cfi_directive;
  426. # CFI directives annotate instructions that are significant for
  427. # stack unwinding procedure compliant with DWARF specification,
  428. # see http://dwarfstd.org/. Besides naturally expected for this
  429. # script platform-specific filtering function, this module adds
  430. # three auxiliary synthetic directives not recognized by [GNU]
  431. # assembler:
  432. #
  433. # - .cfi_push to annotate push instructions in prologue, which
  434. # translates to .cfi_adjust_cfa_offset (if needed) and
  435. # .cfi_offset;
  436. # - .cfi_pop to annotate pop instructions in epilogue, which
  437. # translates to .cfi_adjust_cfa_offset (if needed) and
  438. # .cfi_restore;
  439. # - [and most notably] .cfi_cfa_expression which encodes
  440. # DW_CFA_def_cfa_expression and passes it to .cfi_escape as
  441. # byte vector;
  442. #
  443. # CFA expressions were introduced in DWARF specification version
  444. # 3 and describe how to deduce CFA, Canonical Frame Address. This
  445. # becomes handy if your stack frame is variable and you can't
  446. # spare register for [previous] frame pointer. Suggested directive
  447. # syntax is made-up mix of DWARF operator suffixes [subset of]
  448. # and references to registers with optional bias. Following example
  449. # describes offloaded *original* stack pointer at specific offset
  450. # from *current* stack pointer:
  451. #
  452. # .cfi_cfa_expression %rsp+40,deref,+8
  453. #
  454. # Final +8 has everything to do with the fact that CFA is defined
  455. # as reference to top of caller's stack, and on x86_64 call to
  456. # subroutine pushes 8-byte return address. In other words original
  457. # stack pointer upon entry to a subroutine is 8 bytes off from CFA.
  458. # Below constants are taken from "DWARF Expressions" section of the
  459. # DWARF specification, section is numbered 7.7 in versions 3 and 4.
  460. my %DW_OP_simple = ( # no-arg operators, mapped directly
  461. deref => 0x06, dup => 0x12,
  462. drop => 0x13, over => 0x14,
  463. pick => 0x15, swap => 0x16,
  464. rot => 0x17, xderef => 0x18,
  465. abs => 0x19, and => 0x1a,
  466. div => 0x1b, minus => 0x1c,
  467. mod => 0x1d, mul => 0x1e,
  468. neg => 0x1f, not => 0x20,
  469. or => 0x21, plus => 0x22,
  470. shl => 0x24, shr => 0x25,
  471. shra => 0x26, xor => 0x27,
  472. );
  473. my %DW_OP_complex = ( # used in specific subroutines
  474. constu => 0x10, # uleb128
  475. consts => 0x11, # sleb128
  476. plus_uconst => 0x23, # uleb128
  477. lit0 => 0x30, # add 0-31 to opcode
  478. reg0 => 0x50, # add 0-31 to opcode
  479. breg0 => 0x70, # add 0-31 to opcole, sleb128
  480. regx => 0x90, # uleb28
  481. fbreg => 0x91, # sleb128
  482. bregx => 0x92, # uleb128, sleb128
  483. piece => 0x93, # uleb128
  484. );
  485. # Following constants are defined in x86_64 ABI supplement, for
  486. # example avaiable at https://www.uclibc.org/docs/psABI-x86_64.pdf,
  487. # see section 3.7 "Stack Unwind Algorithm".
  488. my %DW_reg_idx = (
  489. "%rax"=>0, "%rdx"=>1, "%rcx"=>2, "%rbx"=>3,
  490. "%rsi"=>4, "%rdi"=>5, "%rbp"=>6, "%rsp"=>7,
  491. "%r8" =>8, "%r9" =>9, "%r10"=>10, "%r11"=>11,
  492. "%r12"=>12, "%r13"=>13, "%r14"=>14, "%r15"=>15
  493. );
  494. my ($cfa_reg, $cfa_rsp);
  495. # [us]leb128 format is variable-length integer representation base
  496. # 2^128, with most significant bit of each byte being 0 denoting
  497. # *last* most significat digit. See "Variable Length Data" in the
  498. # DWARF specification, numbered 7.6 at least in versions 3 and 4.
  499. sub sleb128 {
  500. use integer; # get right shift extend sign
  501. my $val = shift;
  502. my $sign = ($val < 0) ? -1 : 0;
  503. my @ret = ();
  504. while(1) {
  505. push @ret, $val&0x7f;
  506. # see if remaining bits are same and equal to most
  507. # significant bit of the current digit, if so, it's
  508. # last digit...
  509. last if (($val>>6) == $sign);
  510. @ret[-1] |= 0x80;
  511. $val >>= 7;
  512. }
  513. return @ret;
  514. }
  515. sub uleb128 {
  516. my $val = shift;
  517. my @ret = ();
  518. while(1) {
  519. push @ret, $val&0x7f;
  520. # see if it's last significant digit...
  521. last if (($val >>= 7) == 0);
  522. @ret[-1] |= 0x80;
  523. }
  524. return @ret;
  525. }
  526. sub const {
  527. my $val = shift;
  528. if ($val >= 0 && $val < 32) {
  529. return ($DW_OP_complex{lit0}+$val);
  530. }
  531. return ($DW_OP_complex{consts}, sleb128($val));
  532. }
  533. sub reg {
  534. my $val = shift;
  535. return if ($val !~ m/^(%r\w+)(?:([\+\-])((?:0x)?[0-9a-f]+))?/);
  536. my $reg = $DW_reg_idx{$1};
  537. my $off = eval ("0 $2 $3");
  538. return (($DW_OP_complex{breg0} + $reg), sleb128($off));
  539. # Yes, we use DW_OP_bregX+0 to push register value and not
  540. # DW_OP_regX, because latter would require even DW_OP_piece,
  541. # which would be a waste under the circumstances. If you have
  542. # to use DWP_OP_reg, use "regx:N"...
  543. }
  544. sub cfa_expression {
  545. my $line = shift;
  546. my @ret;
  547. foreach my $token (split(/,\s*/,$line)) {
  548. if ($token =~ /^%r/) {
  549. push @ret,reg($token);
  550. } elsif ($token =~ /((?:0x)?[0-9a-f]+)\((%r\w+)\)/) {
  551. push @ret,reg("$2+$1");
  552. } elsif ($token =~ /(\w+):(\-?(?:0x)?[0-9a-f]+)(U?)/i) {
  553. my $i = 1*eval($2);
  554. push @ret,$DW_OP_complex{$1}, ($3 ? uleb128($i) : sleb128($i));
  555. } elsif (my $i = 1*eval($token) or $token eq "0") {
  556. if ($token =~ /^\+/) {
  557. push @ret,$DW_OP_complex{plus_uconst},uleb128($i);
  558. } else {
  559. push @ret,const($i);
  560. }
  561. } else {
  562. push @ret,$DW_OP_simple{$token};
  563. }
  564. }
  565. # Finally we return DW_CFA_def_cfa_expression, 15, followed by
  566. # length of the expression and of course the expression itself.
  567. return (15,scalar(@ret),@ret);
  568. }
  569. sub re {
  570. my ($class, $line) = @_;
  571. my $self = {};
  572. my $ret;
  573. if ($$line =~ s/^\s*\.cfi_(\w+)\s*//) {
  574. bless $self,$class;
  575. $ret = $self;
  576. undef $self->{value};
  577. my $dir = $1;
  578. SWITCH: for ($dir) {
  579. # What is $cfa_rsp? Effectively it's difference between %rsp
  580. # value and current CFA, Canonical Frame Address, which is
  581. # why it starts with -8. Recall that CFA is top of caller's
  582. # stack...
  583. /startproc/ && do { ($cfa_reg, $cfa_rsp) = ("%rsp", -8); last; };
  584. /endproc/ && do { ($cfa_reg, $cfa_rsp) = ("%rsp", 0); last; };
  585. /def_cfa_register/
  586. && do { $cfa_reg = $$line; last; };
  587. /def_cfa_offset/
  588. && do { $cfa_rsp = -1*eval($$line) if ($cfa_reg eq "%rsp");
  589. last;
  590. };
  591. /adjust_cfa_offset/
  592. && do { $cfa_rsp -= 1*eval($$line) if ($cfa_reg eq "%rsp");
  593. last;
  594. };
  595. /def_cfa/ && do { if ($$line =~ /(%r\w+)\s*,\s*(.+)/) {
  596. $cfa_reg = $1;
  597. $cfa_rsp = -1*eval($2) if ($cfa_reg eq "%rsp");
  598. }
  599. last;
  600. };
  601. /push/ && do { $dir = undef;
  602. $cfa_rsp -= 8;
  603. if ($cfa_reg eq "%rsp") {
  604. $self->{value} = ".cfi_adjust_cfa_offset\t8\n";
  605. }
  606. $self->{value} .= ".cfi_offset\t$$line,$cfa_rsp";
  607. last;
  608. };
  609. /pop/ && do { $dir = undef;
  610. $cfa_rsp += 8;
  611. if ($cfa_reg eq "%rsp") {
  612. $self->{value} = ".cfi_adjust_cfa_offset\t-8\n";
  613. }
  614. $self->{value} .= ".cfi_restore\t$$line";
  615. last;
  616. };
  617. /cfa_expression/
  618. && do { $dir = undef;
  619. $self->{value} = ".cfi_escape\t" .
  620. join(",", map(sprintf("0x%02x", $_),
  621. cfa_expression($$line)));
  622. last;
  623. };
  624. }
  625. $self->{value} = ".cfi_$dir\t$$line" if ($dir);
  626. $$line = "";
  627. }
  628. return $ret;
  629. }
  630. sub out {
  631. my $self = shift;
  632. return ($elf ? $self->{value} : undef);
  633. }
  634. }
  635. { package directive; # pick up directives, which start with .
  636. sub re {
  637. my ($class, $line) = @_;
  638. my $self = {};
  639. my $ret;
  640. my $dir;
  641. # chain-call to cfi_directive
  642. $ret = cfi_directive->re($line) and return $ret;
  643. if ($$line =~ /^\s*(\.\w+)/) {
  644. bless $self,$class;
  645. $dir = $1;
  646. $ret = $self;
  647. undef $self->{value};
  648. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  649. SWITCH: for ($dir) {
  650. /\.global|\.globl|\.extern/
  651. && do { $globals{$$line} = $prefix . $$line;
  652. $$line = $globals{$$line} if ($prefix);
  653. last;
  654. };
  655. /\.type/ && do { my ($sym,$type,$narg) = split(',',$$line);
  656. if ($type eq "\@function") {
  657. undef $current_function;
  658. $current_function->{name} = $sym;
  659. $current_function->{abi} = "svr4";
  660. $current_function->{narg} = $narg;
  661. $current_function->{scope} = defined($globals{$sym})?"PUBLIC":"PRIVATE";
  662. } elsif ($type eq "\@abi-omnipotent") {
  663. undef $current_function;
  664. $current_function->{name} = $sym;
  665. $current_function->{scope} = defined($globals{$sym})?"PUBLIC":"PRIVATE";
  666. }
  667. $$line =~ s/\@abi\-omnipotent/\@function/;
  668. $$line =~ s/\@function.*/\@function/;
  669. last;
  670. };
  671. /\.asciz/ && do { if ($$line =~ /^"(.*)"$/) {
  672. $dir = ".byte";
  673. $$line = join(",",unpack("C*",$1),0);
  674. }
  675. last;
  676. };
  677. /\.rva|\.long|\.quad/
  678. && do { $$line =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
  679. $$line =~ s/\.L/$decor/g;
  680. last;
  681. };
  682. }
  683. if ($gas) {
  684. $self->{value} = $dir . "\t" . $$line;
  685. if ($dir =~ /\.extern/) {
  686. if ($flavour eq "elf") {
  687. $self->{value} .= "\n.hidden $$line";
  688. } else {
  689. $self->{value} = "";
  690. }
  691. } elsif (!$elf && $dir =~ /\.type/) {
  692. $self->{value} = "";
  693. $self->{value} = ".def\t" . ($globals{$1} or $1) . ";\t" .
  694. (defined($globals{$1})?".scl 2;":".scl 3;") .
  695. "\t.type 32;\t.endef"
  696. if ($win64 && $$line =~ /([^,]+),\@function/);
  697. } elsif (!$elf && $dir =~ /\.size/) {
  698. $self->{value} = "";
  699. if (defined($current_function)) {
  700. $self->{value} .= "${decor}SEH_end_$current_function->{name}:"
  701. if ($win64 && $current_function->{abi} eq "svr4");
  702. undef $current_function;
  703. }
  704. } elsif (!$elf && $dir =~ /\.align/) {
  705. $self->{value} = ".p2align\t" . (log($$line)/log(2));
  706. } elsif ($dir eq ".section") {
  707. $current_segment=$$line;
  708. if (!$elf && $current_segment eq ".init") {
  709. if ($flavour eq "macosx") { $self->{value} = ".mod_init_func"; }
  710. elsif ($flavour eq "mingw64") { $self->{value} = ".section\t.ctors"; }
  711. }
  712. } elsif ($dir =~ /\.(text|data)/) {
  713. $current_segment=".$1";
  714. } elsif ($dir =~ /\.global|\.globl|\.extern/) {
  715. if ($flavour eq "macosx") {
  716. $self->{value} .= "\n.private_extern $$line";
  717. } else {
  718. $self->{value} .= "\n.hidden $$line";
  719. }
  720. } elsif ($dir =~ /\.hidden/) {
  721. if ($flavour eq "macosx") { $self->{value} = ".private_extern\t$prefix$$line"; }
  722. elsif ($flavour eq "mingw64") { $self->{value} = ""; }
  723. } elsif ($dir =~ /\.comm/) {
  724. $self->{value} = "$dir\t$prefix$$line";
  725. $self->{value} =~ s|,([0-9]+),([0-9]+)$|",$1,".log($2)/log(2)|e if ($flavour eq "macosx");
  726. }
  727. $$line = "";
  728. return $self;
  729. }
  730. # non-gas case or nasm/masm
  731. SWITCH: for ($dir) {
  732. /\.text/ && do { my $v=undef;
  733. if ($nasm) {
  734. $v="section .text code align=64\n";
  735. } else {
  736. $v="$current_segment\tENDS\n" if ($current_segment);
  737. $current_segment = ".text\$";
  738. $v.="$current_segment\tSEGMENT ";
  739. $v.=$masm>=$masmref ? "ALIGN(256)" : "PAGE";
  740. $v.=" 'CODE'";
  741. }
  742. $self->{value} = $v;
  743. last;
  744. };
  745. /\.data/ && do { my $v=undef;
  746. if ($nasm) {
  747. $v="section .data data align=8\n";
  748. } else {
  749. $v="$current_segment\tENDS\n" if ($current_segment);
  750. $current_segment = "_DATA";
  751. $v.="$current_segment\tSEGMENT";
  752. }
  753. $self->{value} = $v;
  754. last;
  755. };
  756. /\.section/ && do { my $v=undef;
  757. $$line =~ s/([^,]*).*/$1/;
  758. $$line = ".CRT\$XCU" if ($$line eq ".init");
  759. if ($nasm) {
  760. $v="section $$line";
  761. if ($$line=~/\.([px])data/) {
  762. $v.=" rdata align=";
  763. $v.=$1 eq "p"? 4 : 8;
  764. } elsif ($$line=~/\.CRT\$/i) {
  765. $v.=" rdata align=8";
  766. }
  767. } else {
  768. $v="$current_segment\tENDS\n" if ($current_segment);
  769. $v.="$$line\tSEGMENT";
  770. if ($$line=~/\.([px])data/) {
  771. $v.=" READONLY";
  772. $v.=" ALIGN(".($1 eq "p" ? 4 : 8).")" if ($masm>=$masmref);
  773. } elsif ($$line=~/\.CRT\$/i) {
  774. $v.=" READONLY ";
  775. $v.=$masm>=$masmref ? "ALIGN(8)" : "DWORD";
  776. }
  777. }
  778. $current_segment = $$line;
  779. $self->{value} = $v;
  780. last;
  781. };
  782. /\.extern/ && do { $self->{value} = "EXTERN\t".$$line;
  783. $self->{value} .= ":NEAR" if ($masm);
  784. last;
  785. };
  786. /\.globl|.global/
  787. && do { $self->{value} = $masm?"PUBLIC":"global";
  788. $self->{value} .= "\t".$$line;
  789. last;
  790. };
  791. /\.size/ && do { if (defined($current_function)) {
  792. undef $self->{value};
  793. if ($current_function->{abi} eq "svr4") {
  794. $self->{value}="${decor}SEH_end_$current_function->{name}:";
  795. $self->{value}.=":\n" if($masm);
  796. }
  797. $self->{value}.="$current_function->{name}\tENDP" if($masm && $current_function->{name});
  798. undef $current_function;
  799. }
  800. last;
  801. };
  802. /\.align/ && do { my $max = ($masm && $masm>=$masmref) ? 256 : 4096;
  803. $self->{value} = "ALIGN\t".($$line>$max?$max:$$line);
  804. last;
  805. };
  806. /\.(value|long|rva|quad)/
  807. && do { my $sz = substr($1,0,1);
  808. my @arr = split(/,\s*/,$$line);
  809. my $last = pop(@arr);
  810. my $conv = sub { my $var=shift;
  811. $var=~s/^(0b[0-1]+)/oct($1)/eig;
  812. $var=~s/^0x([0-9a-f]+)/0$1h/ig if ($masm);
  813. if ($sz eq "D" && ($current_segment=~/.[px]data/ || $dir eq ".rva"))
  814. { $var=~s/([_a-z\$\@][_a-z0-9\$\@]*)/$nasm?"$1 wrt ..imagebase":"imagerel $1"/egi; }
  815. $var;
  816. };
  817. $sz =~ tr/bvlrq/BWDDQ/;
  818. $self->{value} = "\tD$sz\t";
  819. for (@arr) { $self->{value} .= &$conv($_).","; }
  820. $self->{value} .= &$conv($last);
  821. last;
  822. };
  823. /\.byte/ && do { my @str=split(/,\s*/,$$line);
  824. map(s/(0b[0-1]+)/oct($1)/eig,@str);
  825. map(s/0x([0-9a-f]+)/0$1h/ig,@str) if ($masm);
  826. while ($#str>15) {
  827. $self->{value}.="DB\t"
  828. .join(",",@str[0..15])."\n";
  829. foreach (0..15) { shift @str; }
  830. }
  831. $self->{value}.="DB\t"
  832. .join(",",@str) if (@str);
  833. last;
  834. };
  835. /\.comm/ && do { my @str=split(/,\s*/,$$line);
  836. my $v=undef;
  837. if ($nasm) {
  838. $v.="common $prefix@str[0] @str[1]";
  839. } else {
  840. $v="$current_segment\tENDS\n" if ($current_segment);
  841. $current_segment = "_DATA";
  842. $v.="$current_segment\tSEGMENT\n";
  843. $v.="COMM @str[0]:DWORD:".@str[1]/4;
  844. }
  845. $self->{value} = $v;
  846. last;
  847. };
  848. }
  849. $$line = "";
  850. }
  851. $ret;
  852. }
  853. sub out {
  854. my $self = shift;
  855. $self->{value};
  856. }
  857. }
  858. # Upon initial x86_64 introduction SSE>2 extensions were not introduced
  859. # yet. In order not to be bothered by tracing exact assembler versions,
  860. # but at the same time to provide a bare security minimum of AES-NI, we
  861. # hard-code some instructions. Extensions past AES-NI on the other hand
  862. # are traced by examining assembler version in individual perlasm
  863. # modules...
  864. my %regrm = ( "%eax"=>0, "%ecx"=>1, "%edx"=>2, "%ebx"=>3,
  865. "%esp"=>4, "%ebp"=>5, "%esi"=>6, "%edi"=>7 );
  866. sub rex {
  867. my $opcode=shift;
  868. my ($dst,$src,$rex)=@_;
  869. $rex|=0x04 if($dst>=8);
  870. $rex|=0x01 if($src>=8);
  871. push @$opcode,($rex|0x40) if ($rex);
  872. }
  873. my $movq = sub { # elderly gas can't handle inter-register movq
  874. my $arg = shift;
  875. my @opcode=(0x66);
  876. if ($arg =~ /%xmm([0-9]+),\s*%r(\w+)/) {
  877. my ($src,$dst)=($1,$2);
  878. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  879. rex(\@opcode,$src,$dst,0x8);
  880. push @opcode,0x0f,0x7e;
  881. push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
  882. @opcode;
  883. } elsif ($arg =~ /%r(\w+),\s*%xmm([0-9]+)/) {
  884. my ($src,$dst)=($2,$1);
  885. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  886. rex(\@opcode,$src,$dst,0x8);
  887. push @opcode,0x0f,0x6e;
  888. push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
  889. @opcode;
  890. } else {
  891. ();
  892. }
  893. };
  894. my $pextrd = sub {
  895. if (shift =~ /\$([0-9]+),\s*%xmm([0-9]+),\s*(%\w+)/) {
  896. my @opcode=(0x66);
  897. my $imm=$1;
  898. my $src=$2;
  899. my $dst=$3;
  900. if ($dst =~ /%r([0-9]+)d/) { $dst = $1; }
  901. elsif ($dst =~ /%e/) { $dst = $regrm{$dst}; }
  902. rex(\@opcode,$src,$dst);
  903. push @opcode,0x0f,0x3a,0x16;
  904. push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
  905. push @opcode,$imm;
  906. @opcode;
  907. } else {
  908. ();
  909. }
  910. };
  911. my $pinsrd = sub {
  912. if (shift =~ /\$([0-9]+),\s*(%\w+),\s*%xmm([0-9]+)/) {
  913. my @opcode=(0x66);
  914. my $imm=$1;
  915. my $src=$2;
  916. my $dst=$3;
  917. if ($src =~ /%r([0-9]+)/) { $src = $1; }
  918. elsif ($src =~ /%e/) { $src = $regrm{$src}; }
  919. rex(\@opcode,$dst,$src);
  920. push @opcode,0x0f,0x3a,0x22;
  921. push @opcode,0xc0|(($dst&7)<<3)|($src&7); # ModR/M
  922. push @opcode,$imm;
  923. @opcode;
  924. } else {
  925. ();
  926. }
  927. };
  928. my $pshufb = sub {
  929. if (shift =~ /%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  930. my @opcode=(0x66);
  931. rex(\@opcode,$2,$1);
  932. push @opcode,0x0f,0x38,0x00;
  933. push @opcode,0xc0|($1&7)|(($2&7)<<3); # ModR/M
  934. @opcode;
  935. } else {
  936. ();
  937. }
  938. };
  939. my $palignr = sub {
  940. if (shift =~ /\$([0-9]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  941. my @opcode=(0x66);
  942. rex(\@opcode,$3,$2);
  943. push @opcode,0x0f,0x3a,0x0f;
  944. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  945. push @opcode,$1;
  946. @opcode;
  947. } else {
  948. ();
  949. }
  950. };
  951. my $pclmulqdq = sub {
  952. if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  953. my @opcode=(0x66);
  954. rex(\@opcode,$3,$2);
  955. push @opcode,0x0f,0x3a,0x44;
  956. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  957. my $c=$1;
  958. push @opcode,$c=~/^0/?oct($c):$c;
  959. @opcode;
  960. } else {
  961. ();
  962. }
  963. };
  964. my $rdrand = sub {
  965. if (shift =~ /%[er](\w+)/) {
  966. my @opcode=();
  967. my $dst=$1;
  968. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  969. rex(\@opcode,0,$dst,8);
  970. push @opcode,0x0f,0xc7,0xf0|($dst&7);
  971. @opcode;
  972. } else {
  973. ();
  974. }
  975. };
  976. my $rdseed = sub {
  977. if (shift =~ /%[er](\w+)/) {
  978. my @opcode=();
  979. my $dst=$1;
  980. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  981. rex(\@opcode,0,$dst,8);
  982. push @opcode,0x0f,0xc7,0xf8|($dst&7);
  983. @opcode;
  984. } else {
  985. ();
  986. }
  987. };
  988. # Not all AVX-capable assemblers recognize AMD XOP extension. Since we
  989. # are using only two instructions hand-code them in order to be excused
  990. # from chasing assembler versions...
  991. sub rxb {
  992. my $opcode=shift;
  993. my ($dst,$src1,$src2,$rxb)=@_;
  994. $rxb|=0x7<<5;
  995. $rxb&=~(0x04<<5) if($dst>=8);
  996. $rxb&=~(0x01<<5) if($src1>=8);
  997. $rxb&=~(0x02<<5) if($src2>=8);
  998. push @$opcode,$rxb;
  999. }
  1000. my $vprotd = sub {
  1001. if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  1002. my @opcode=(0x8f);
  1003. rxb(\@opcode,$3,$2,-1,0x08);
  1004. push @opcode,0x78,0xc2;
  1005. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  1006. my $c=$1;
  1007. push @opcode,$c=~/^0/?oct($c):$c;
  1008. @opcode;
  1009. } else {
  1010. ();
  1011. }
  1012. };
  1013. my $vprotq = sub {
  1014. if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  1015. my @opcode=(0x8f);
  1016. rxb(\@opcode,$3,$2,-1,0x08);
  1017. push @opcode,0x78,0xc3;
  1018. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  1019. my $c=$1;
  1020. push @opcode,$c=~/^0/?oct($c):$c;
  1021. @opcode;
  1022. } else {
  1023. ();
  1024. }
  1025. };
  1026. # Intel Control-flow Enforcement Technology extension. All functions and
  1027. # indirect branch targets will have to start with this instruction...
  1028. my $endbranch = sub {
  1029. (0xf3,0x0f,0x1e,0xfa);
  1030. };
  1031. ########################################################################
  1032. if ($nasm) {
  1033. print <<___;
  1034. default rel
  1035. %define XMMWORD
  1036. %define YMMWORD
  1037. %define ZMMWORD
  1038. ___
  1039. } elsif ($masm) {
  1040. print <<___;
  1041. OPTION DOTNAME
  1042. ___
  1043. }
  1044. print STDOUT "#if defined(__x86_64__) && !defined(OPENSSL_NO_ASM)\n" if ($gas);
  1045. while(defined(my $line=<>)) {
  1046. $line =~ s|\R$||; # Better chomp
  1047. $line =~ s|[#!].*$||; # get rid of asm-style comments...
  1048. $line =~ s|/\*.*\*/||; # ... and C-style comments...
  1049. $line =~ s|^\s+||; # ... and skip white spaces in beginning
  1050. $line =~ s|\s+$||; # ... and at the end
  1051. if (my $label=label->re(\$line)) { print $label->out(); }
  1052. if (my $directive=directive->re(\$line)) {
  1053. printf "%s",$directive->out();
  1054. } elsif (my $opcode=opcode->re(\$line)) {
  1055. my $asm = eval("\$".$opcode->mnemonic());
  1056. if ((ref($asm) eq 'CODE') && scalar(my @bytes=&$asm($line))) {
  1057. print $gas?".byte\t":"DB\t",join(',',@bytes),"\n";
  1058. next;
  1059. }
  1060. my @args;
  1061. ARGUMENT: while (1) {
  1062. my $arg;
  1063. ($arg=register->re(\$line, $opcode))||
  1064. ($arg=const->re(\$line)) ||
  1065. ($arg=ea->re(\$line, $opcode)) ||
  1066. ($arg=expr->re(\$line, $opcode)) ||
  1067. last ARGUMENT;
  1068. push @args,$arg;
  1069. last ARGUMENT if ($line !~ /^,/);
  1070. $line =~ s/^,\s*//;
  1071. } # ARGUMENT:
  1072. if ($#args>=0) {
  1073. my $insn;
  1074. my $sz=$opcode->size();
  1075. if ($gas) {
  1076. $insn = $opcode->out($#args>=1?$args[$#args]->size():$sz);
  1077. @args = map($_->out($sz),@args);
  1078. printf "\t%s\t%s",$insn,join(",",@args);
  1079. } else {
  1080. $insn = $opcode->out();
  1081. foreach (@args) {
  1082. my $arg = $_->out();
  1083. # $insn.=$sz compensates for movq, pinsrw, ...
  1084. if ($arg =~ /^xmm[0-9]+$/) { $insn.=$sz; $sz="x" if(!$sz); last; }
  1085. if ($arg =~ /^ymm[0-9]+$/) { $insn.=$sz; $sz="y" if(!$sz); last; }
  1086. if ($arg =~ /^zmm[0-9]+$/) { $insn.=$sz; $sz="z" if(!$sz); last; }
  1087. if ($arg =~ /^mm[0-9]+$/) { $insn.=$sz; $sz="q" if(!$sz); last; }
  1088. }
  1089. @args = reverse(@args);
  1090. undef $sz if ($nasm && $opcode->mnemonic() eq "lea");
  1091. if ($insn eq "movq" && $#args == 1 && $args[0]->out($sz) eq "xmm0" && $args[1]->out($sz) eq "rax") {
  1092. # I have no clue why MASM can't parse this instruction.
  1093. printf "DB 66h, 48h, 0fh, 6eh, 0c0h";
  1094. } else {
  1095. printf "\t%s\t%s",$insn,join(",",map($_->out($sz),@args));
  1096. }
  1097. }
  1098. } else {
  1099. printf "\t%s",$opcode->out();
  1100. }
  1101. }
  1102. print $line,"\n";
  1103. }
  1104. print "\n$current_segment\tENDS\n" if ($current_segment && $masm);
  1105. print "END\n" if ($masm);
  1106. print "#endif\n" if ($gas);
  1107. close STDOUT;
  1108. #################################################
  1109. # Cross-reference x86_64 ABI "card"
  1110. #
  1111. # Unix Win64
  1112. # %rax * *
  1113. # %rbx - -
  1114. # %rcx #4 #1
  1115. # %rdx #3 #2
  1116. # %rsi #2 -
  1117. # %rdi #1 -
  1118. # %rbp - -
  1119. # %rsp - -
  1120. # %r8 #5 #3
  1121. # %r9 #6 #4
  1122. # %r10 * *
  1123. # %r11 * *
  1124. # %r12 - -
  1125. # %r13 - -
  1126. # %r14 - -
  1127. # %r15 - -
  1128. #
  1129. # (*) volatile register
  1130. # (-) preserved by callee
  1131. # (#) Nth argument, volatile
  1132. #
  1133. # In Unix terms top of stack is argument transfer area for arguments
  1134. # which could not be accommodated in registers. Or in other words 7th
  1135. # [integer] argument resides at 8(%rsp) upon function entry point.
  1136. # 128 bytes above %rsp constitute a "red zone" which is not touched
  1137. # by signal handlers and can be used as temporal storage without
  1138. # allocating a frame.
  1139. #
  1140. # In Win64 terms N*8 bytes on top of stack is argument transfer area,
  1141. # which belongs to/can be overwritten by callee. N is the number of
  1142. # arguments passed to callee, *but* not less than 4! This means that
  1143. # upon function entry point 5th argument resides at 40(%rsp), as well
  1144. # as that 32 bytes from 8(%rsp) can always be used as temporal
  1145. # storage [without allocating a frame]. One can actually argue that
  1146. # one can assume a "red zone" above stack pointer under Win64 as well.
  1147. # Point is that at apparently no occasion Windows kernel would alter
  1148. # the area above user stack pointer in true asynchronous manner...
  1149. #
  1150. # All the above means that if assembler programmer adheres to Unix
  1151. # register and stack layout, but disregards the "red zone" existence,
  1152. # it's possible to use following prologue and epilogue to "gear" from
  1153. # Unix to Win64 ABI in leaf functions with not more than 6 arguments.
  1154. #
  1155. # omnipotent_function:
  1156. # ifdef WIN64
  1157. # movq %rdi,8(%rsp)
  1158. # movq %rsi,16(%rsp)
  1159. # movq %rcx,%rdi ; if 1st argument is actually present
  1160. # movq %rdx,%rsi ; if 2nd argument is actually ...
  1161. # movq %r8,%rdx ; if 3rd argument is ...
  1162. # movq %r9,%rcx ; if 4th argument ...
  1163. # movq 40(%rsp),%r8 ; if 5th ...
  1164. # movq 48(%rsp),%r9 ; if 6th ...
  1165. # endif
  1166. # ...
  1167. # ifdef WIN64
  1168. # movq 8(%rsp),%rdi
  1169. # movq 16(%rsp),%rsi
  1170. # endif
  1171. # ret
  1172. #
  1173. #################################################
  1174. # Win64 SEH, Structured Exception Handling.
  1175. #
  1176. # Unlike on Unix systems(*) lack of Win64 stack unwinding information
  1177. # has undesired side-effect at run-time: if an exception is raised in
  1178. # assembler subroutine such as those in question (basically we're
  1179. # referring to segmentation violations caused by malformed input
  1180. # parameters), the application is briskly terminated without invoking
  1181. # any exception handlers, most notably without generating memory dump
  1182. # or any user notification whatsoever. This poses a problem. It's
  1183. # possible to address it by registering custom language-specific
  1184. # handler that would restore processor context to the state at
  1185. # subroutine entry point and return "exception is not handled, keep
  1186. # unwinding" code. Writing such handler can be a challenge... But it's
  1187. # doable, though requires certain coding convention. Consider following
  1188. # snippet:
  1189. #
  1190. # .type function,@function
  1191. # function:
  1192. # movq %rsp,%rax # copy rsp to volatile register
  1193. # pushq %r15 # save non-volatile registers
  1194. # pushq %rbx
  1195. # pushq %rbp
  1196. # movq %rsp,%r11
  1197. # subq %rdi,%r11 # prepare [variable] stack frame
  1198. # andq $-64,%r11
  1199. # movq %rax,0(%r11) # check for exceptions
  1200. # movq %r11,%rsp # allocate [variable] stack frame
  1201. # movq %rax,0(%rsp) # save original rsp value
  1202. # magic_point:
  1203. # ...
  1204. # movq 0(%rsp),%rcx # pull original rsp value
  1205. # movq -24(%rcx),%rbp # restore non-volatile registers
  1206. # movq -16(%rcx),%rbx
  1207. # movq -8(%rcx),%r15
  1208. # movq %rcx,%rsp # restore original rsp
  1209. # magic_epilogue:
  1210. # ret
  1211. # .size function,.-function
  1212. #
  1213. # The key is that up to magic_point copy of original rsp value remains
  1214. # in chosen volatile register and no non-volatile register, except for
  1215. # rsp, is modified. While past magic_point rsp remains constant till
  1216. # the very end of the function. In this case custom language-specific
  1217. # exception handler would look like this:
  1218. #
  1219. # EXCEPTION_DISPOSITION handler (EXCEPTION_RECORD *rec,ULONG64 frame,
  1220. # CONTEXT *context,DISPATCHER_CONTEXT *disp)
  1221. # { ULONG64 *rsp = (ULONG64 *)context->Rax;
  1222. # ULONG64 rip = context->Rip;
  1223. #
  1224. # if (rip >= magic_point)
  1225. # { rsp = (ULONG64 *)context->Rsp;
  1226. # if (rip < magic_epilogue)
  1227. # { rsp = (ULONG64 *)rsp[0];
  1228. # context->Rbp = rsp[-3];
  1229. # context->Rbx = rsp[-2];
  1230. # context->R15 = rsp[-1];
  1231. # }
  1232. # }
  1233. # context->Rsp = (ULONG64)rsp;
  1234. # context->Rdi = rsp[1];
  1235. # context->Rsi = rsp[2];
  1236. #
  1237. # memcpy (disp->ContextRecord,context,sizeof(CONTEXT));
  1238. # RtlVirtualUnwind(UNW_FLAG_NHANDLER,disp->ImageBase,
  1239. # dips->ControlPc,disp->FunctionEntry,disp->ContextRecord,
  1240. # &disp->HandlerData,&disp->EstablisherFrame,NULL);
  1241. # return ExceptionContinueSearch;
  1242. # }
  1243. #
  1244. # It's appropriate to implement this handler in assembler, directly in
  1245. # function's module. In order to do that one has to know members'
  1246. # offsets in CONTEXT and DISPATCHER_CONTEXT structures and some constant
  1247. # values. Here they are:
  1248. #
  1249. # CONTEXT.Rax 120
  1250. # CONTEXT.Rcx 128
  1251. # CONTEXT.Rdx 136
  1252. # CONTEXT.Rbx 144
  1253. # CONTEXT.Rsp 152
  1254. # CONTEXT.Rbp 160
  1255. # CONTEXT.Rsi 168
  1256. # CONTEXT.Rdi 176
  1257. # CONTEXT.R8 184
  1258. # CONTEXT.R9 192
  1259. # CONTEXT.R10 200
  1260. # CONTEXT.R11 208
  1261. # CONTEXT.R12 216
  1262. # CONTEXT.R13 224
  1263. # CONTEXT.R14 232
  1264. # CONTEXT.R15 240
  1265. # CONTEXT.Rip 248
  1266. # CONTEXT.Xmm6 512
  1267. # sizeof(CONTEXT) 1232
  1268. # DISPATCHER_CONTEXT.ControlPc 0
  1269. # DISPATCHER_CONTEXT.ImageBase 8
  1270. # DISPATCHER_CONTEXT.FunctionEntry 16
  1271. # DISPATCHER_CONTEXT.EstablisherFrame 24
  1272. # DISPATCHER_CONTEXT.TargetIp 32
  1273. # DISPATCHER_CONTEXT.ContextRecord 40
  1274. # DISPATCHER_CONTEXT.LanguageHandler 48
  1275. # DISPATCHER_CONTEXT.HandlerData 56
  1276. # UNW_FLAG_NHANDLER 0
  1277. # ExceptionContinueSearch 1
  1278. #
  1279. # In order to tie the handler to the function one has to compose
  1280. # couple of structures: one for .xdata segment and one for .pdata.
  1281. #
  1282. # UNWIND_INFO structure for .xdata segment would be
  1283. #
  1284. # function_unwind_info:
  1285. # .byte 9,0,0,0
  1286. # .rva handler
  1287. #
  1288. # This structure designates exception handler for a function with
  1289. # zero-length prologue, no stack frame or frame register.
  1290. #
  1291. # To facilitate composing of .pdata structures, auto-generated "gear"
  1292. # prologue copies rsp value to rax and denotes next instruction with
  1293. # .LSEH_begin_{function_name} label. This essentially defines the SEH
  1294. # styling rule mentioned in the beginning. Position of this label is
  1295. # chosen in such manner that possible exceptions raised in the "gear"
  1296. # prologue would be accounted to caller and unwound from latter's frame.
  1297. # End of function is marked with respective .LSEH_end_{function_name}
  1298. # label. To summarize, .pdata segment would contain
  1299. #
  1300. # .rva .LSEH_begin_function
  1301. # .rva .LSEH_end_function
  1302. # .rva function_unwind_info
  1303. #
  1304. # Reference to function_unwind_info from .xdata segment is the anchor.
  1305. # In case you wonder why references are 32-bit .rvas and not 64-bit
  1306. # .quads. References put into these two segments are required to be
  1307. # *relative* to the base address of the current binary module, a.k.a.
  1308. # image base. No Win64 module, be it .exe or .dll, can be larger than
  1309. # 2GB and thus such relative references can be and are accommodated in
  1310. # 32 bits.
  1311. #
  1312. # Having reviewed the example function code, one can argue that "movq
  1313. # %rsp,%rax" above is redundant. It is not! Keep in mind that on Unix
  1314. # rax would contain an undefined value. If this "offends" you, use
  1315. # another register and refrain from modifying rax till magic_point is
  1316. # reached, i.e. as if it was a non-volatile register. If more registers
  1317. # are required prior [variable] frame setup is completed, note that
  1318. # nobody says that you can have only one "magic point." You can
  1319. # "liberate" non-volatile registers by denoting last stack off-load
  1320. # instruction and reflecting it in finer grade unwind logic in handler.
  1321. # After all, isn't it why it's called *language-specific* handler...
  1322. #
  1323. # SE handlers are also involved in unwinding stack when executable is
  1324. # profiled or debugged. Profiling implies additional limitations that
  1325. # are too subtle to discuss here. For now it's sufficient to say that
  1326. # in order to simplify handlers one should either a) offload original
  1327. # %rsp to stack (like discussed above); or b) if you have a register to
  1328. # spare for frame pointer, choose volatile one.
  1329. #
  1330. # (*) Note that we're talking about run-time, not debug-time. Lack of
  1331. # unwind information makes debugging hard on both Windows and
  1332. # Unix. "Unlike" referes to the fact that on Unix signal handler
  1333. # will always be invoked, core dumped and appropriate exit code
  1334. # returned to parent (for user notification).