You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
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>
преди 8 години
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200
  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. To support legacy code a synthetic directive, .picmeup,
  53. # is implemented. It puts address of the *next* instruction into
  54. # target register, e.g.:
  55. #
  56. # .picmeup %rax
  57. # lea .Label-.(%rax),%rax
  58. #
  59. # 8. In order to provide for structured exception handling unified
  60. # Win64 prologue copies %rsp value to %rax. For further details
  61. # see SEH paragraph at the end.
  62. # 9. .init segment is allowed to contain calls to functions only.
  63. # a. If function accepts more than 4 arguments *and* >4th argument
  64. # is declared as non 64-bit value, do clear its upper part.
  65. use strict;
  66. my $flavour = shift;
  67. my $output = shift;
  68. if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
  69. open STDOUT,">$output" || die "can't open $output: $!"
  70. if (defined($output));
  71. my $gas=1; $gas=0 if ($output =~ /\.asm$/);
  72. my $elf=1; $elf=0 if (!$gas);
  73. my $win64=0;
  74. my $prefix="";
  75. my $decor=".L";
  76. my $masmref=8 + 50727*2**-32; # 8.00.50727 shipped with VS2005
  77. my $masm=0;
  78. my $PTR=" PTR";
  79. my $nasmref=2.03;
  80. my $nasm=0;
  81. if ($flavour eq "mingw64") { $gas=1; $elf=0; $win64=1;
  82. # TODO(davidben): Before supporting the
  83. # mingw64 perlasm flavour, do away with this
  84. # environment variable check.
  85. die "mingw64 not supported";
  86. $prefix=`echo __USER_LABEL_PREFIX__ | $ENV{CC} -E -P -`;
  87. $prefix =~ s|\R$||; # Better chomp
  88. }
  89. elsif ($flavour eq "macosx") { $gas=1; $elf=0; $prefix="_"; $decor="L\$"; }
  90. elsif ($flavour eq "masm") { $gas=0; $elf=0; $masm=$masmref; $win64=1; $decor="\$L\$"; }
  91. elsif ($flavour eq "nasm") { $gas=0; $elf=0; $nasm=$nasmref; $win64=1; $decor="\$L\$"; $PTR=""; }
  92. elsif (!$gas) { die "unknown flavour $flavour"; }
  93. my $current_segment;
  94. my $current_function;
  95. my %globals;
  96. { package opcode; # pick up opcodes
  97. sub re {
  98. my ($class, $line) = @_;
  99. my $self = {};
  100. my $ret;
  101. if ($$line =~ /^([a-z][a-z0-9]*)/i) {
  102. bless $self,$class;
  103. $self->{op} = $1;
  104. $ret = $self;
  105. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  106. undef $self->{sz};
  107. if ($self->{op} =~ /^(movz)x?([bw]).*/) { # movz is pain...
  108. $self->{op} = $1;
  109. $self->{sz} = $2;
  110. } elsif ($self->{op} =~ /call|jmp/) {
  111. $self->{sz} = "";
  112. } elsif ($self->{op} =~ /^p/ && $' !~ /^(ush|op|insrw)/) { # SSEn
  113. $self->{sz} = "";
  114. } elsif ($self->{op} =~ /^v/) { # VEX
  115. $self->{sz} = "";
  116. } elsif ($self->{op} =~ /mov[dq]/ && $$line =~ /%xmm/) {
  117. $self->{sz} = "";
  118. } elsif ($self->{op} =~ /([a-z]{3,})([qlwb])$/) {
  119. $self->{op} = $1;
  120. $self->{sz} = $2;
  121. }
  122. }
  123. $ret;
  124. }
  125. sub size {
  126. my ($self, $sz) = @_;
  127. $self->{sz} = $sz if (defined($sz) && !defined($self->{sz}));
  128. $self->{sz};
  129. }
  130. sub out {
  131. my $self = shift;
  132. if ($gas) {
  133. if ($self->{op} eq "movz") { # movz is pain...
  134. sprintf "%s%s%s",$self->{op},$self->{sz},shift;
  135. } elsif ($self->{op} =~ /^set/) {
  136. "$self->{op}";
  137. } elsif ($self->{op} eq "ret") {
  138. my $epilogue = "";
  139. if ($win64 && $current_function->{abi} eq "svr4") {
  140. $epilogue = "movq 8(%rsp),%rdi\n\t" .
  141. "movq 16(%rsp),%rsi\n\t";
  142. }
  143. $epilogue . ".byte 0xf3,0xc3";
  144. } elsif ($self->{op} eq "call" && !$elf && $current_segment eq ".init") {
  145. ".p2align\t3\n\t.quad";
  146. } else {
  147. "$self->{op}$self->{sz}";
  148. }
  149. } else {
  150. $self->{op} =~ s/^movz/movzx/;
  151. if ($self->{op} eq "ret") {
  152. $self->{op} = "";
  153. if ($win64 && $current_function->{abi} eq "svr4") {
  154. $self->{op} = "mov rdi,QWORD$PTR\[8+rsp\]\t;WIN64 epilogue\n\t".
  155. "mov rsi,QWORD$PTR\[16+rsp\]\n\t";
  156. }
  157. $self->{op} .= "DB\t0F3h,0C3h\t\t;repret";
  158. } elsif ($self->{op} =~ /^(pop|push)f/) {
  159. $self->{op} .= $self->{sz};
  160. } elsif ($self->{op} eq "call" && $current_segment eq ".CRT\$XCU") {
  161. $self->{op} = "\tDQ";
  162. }
  163. $self->{op};
  164. }
  165. }
  166. sub mnemonic {
  167. my ($self, $op) = @_;
  168. $self->{op}=$op if (defined($op));
  169. $self->{op};
  170. }
  171. }
  172. { package const; # pick up constants, which start with $
  173. sub re {
  174. my ($class, $line) = @_;
  175. my $self = {};
  176. my $ret;
  177. if ($$line =~ /^\$([^,]+)/) {
  178. bless $self, $class;
  179. $self->{value} = $1;
  180. $ret = $self;
  181. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  182. }
  183. $ret;
  184. }
  185. sub out {
  186. my $self = shift;
  187. $self->{value} =~ s/\b(0b[0-1]+)/oct($1)/eig;
  188. if ($gas) {
  189. # Solaris /usr/ccs/bin/as can't handle multiplications
  190. # in $self->{value}
  191. my $value = $self->{value};
  192. no warnings; # oct might complain about overflow, ignore here...
  193. $value =~ s/(?<![\w\$\.])(0x?[0-9a-f]+)/oct($1)/egi;
  194. if ($value =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg) {
  195. $self->{value} = $value;
  196. }
  197. sprintf "\$%s",$self->{value};
  198. } else {
  199. $self->{value} =~ s/0x([0-9a-f]+)/0$1h/ig if ($masm);
  200. sprintf "%s",$self->{value};
  201. }
  202. }
  203. }
  204. { package ea; # pick up effective addresses: expr(%reg,%reg,scale)
  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. $ret = $self;
  217. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  218. if ($win64 && $self->{label} =~ s/\@GOTPCREL//) {
  219. die if ($opcode->mnemonic() ne "mov");
  220. $opcode->mnemonic("lea");
  221. }
  222. $self->{base} =~ s/^%//;
  223. $self->{index} =~ s/^%// if (defined($self->{index}));
  224. $self->{opcode} = $opcode;
  225. }
  226. $ret;
  227. }
  228. sub size {}
  229. sub out {
  230. my ($self, $sz) = @_;
  231. $self->{label} =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
  232. $self->{label} =~ s/\.L/$decor/g;
  233. # Silently convert all EAs to 64-bit. This is required for
  234. # elder GNU assembler and results in more compact code,
  235. # *but* most importantly AES module depends on this feature!
  236. $self->{index} =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
  237. $self->{base} =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
  238. # Solaris /usr/ccs/bin/as can't handle multiplications
  239. # in $self->{label}...
  240. use integer;
  241. $self->{label} =~ s/(?<![\w\$\.])(0x?[0-9a-f]+)/oct($1)/egi;
  242. $self->{label} =~ s/\b([0-9]+\s*[\*\/\%]\s*[0-9]+)\b/eval($1)/eg;
  243. # Some assemblers insist on signed presentation of 32-bit
  244. # offsets, but sign extension is a tricky business in perl...
  245. if ((1<<31)<<1) {
  246. $self->{label} =~ s/\b([0-9]+)\b/$1<<32>>32/eg;
  247. } else {
  248. $self->{label} =~ s/\b([0-9]+)\b/$1>>0/eg;
  249. }
  250. if (!$self->{label} && $self->{index} && $self->{scale}==1 &&
  251. $self->{base} =~ /(rbp|r13)/) {
  252. $self->{base} = $self->{index}; $self->{index} = $1;
  253. }
  254. if ($gas) {
  255. $self->{label} =~ s/^___imp_/__imp__/ if ($flavour eq "mingw64");
  256. if (defined($self->{index})) {
  257. sprintf "%s%s(%s,%%%s,%d)",$self->{asterisk},
  258. $self->{label},
  259. $self->{base}?"%$self->{base}":"",
  260. $self->{index},$self->{scale};
  261. } else {
  262. sprintf "%s%s(%%%s)", $self->{asterisk},$self->{label},$self->{base};
  263. }
  264. } else {
  265. my %szmap = ( b=>"BYTE$PTR", w=>"WORD$PTR",
  266. l=>"DWORD$PTR", d=>"DWORD$PTR",
  267. q=>"QWORD$PTR", o=>"OWORD$PTR",
  268. x=>"XMMWORD$PTR", y=>"YMMWORD$PTR", z=>"ZMMWORD$PTR" );
  269. $self->{label} =~ s/\./\$/g;
  270. $self->{label} =~ s/(?<![\w\$\.])0x([0-9a-f]+)/0$1h/ig;
  271. $self->{label} = "($self->{label})" if ($self->{label} =~ /[\*\+\-\/]/);
  272. my $mnemonic = $self->{opcode}->mnemonic();
  273. ($self->{asterisk}) && ($sz="q") ||
  274. ($mnemonic =~ /^v?mov([qd])$/) && ($sz=$1) ||
  275. ($mnemonic =~ /^v?pinsr([qdwb])$/) && ($sz=$1) ||
  276. ($mnemonic =~ /^vpbroadcast([qdwb])$/) && ($sz=$1) ||
  277. ($mnemonic =~ /^v(?!perm)[a-z]+[fi]128$/) && ($sz="x");
  278. if (defined($self->{index})) {
  279. sprintf "%s[%s%s*%d%s]",$szmap{$sz},
  280. $self->{label}?"$self->{label}+":"",
  281. $self->{index},$self->{scale},
  282. $self->{base}?"+$self->{base}":"";
  283. } elsif ($self->{base} eq "rip") {
  284. sprintf "%s[%s]",$szmap{$sz},$self->{label};
  285. } else {
  286. sprintf "%s[%s%s]",$szmap{$sz},
  287. $self->{label}?"$self->{label}+":"",
  288. $self->{base};
  289. }
  290. }
  291. }
  292. }
  293. { package register; # pick up registers, which start with %.
  294. sub re {
  295. my ($class, $line, $opcode) = @_;
  296. my $self = {};
  297. my $ret;
  298. # optional * ----vvv--- appears in indirect jmp/call
  299. if ($$line =~ /^(\*?)%(\w+)/) {
  300. bless $self,$class;
  301. $self->{asterisk} = $1;
  302. $self->{value} = $2;
  303. $opcode->size($self->size());
  304. $ret = $self;
  305. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  306. }
  307. $ret;
  308. }
  309. sub size {
  310. my $self = shift;
  311. my $ret;
  312. if ($self->{value} =~ /^r[\d]+b$/i) { $ret="b"; }
  313. elsif ($self->{value} =~ /^r[\d]+w$/i) { $ret="w"; }
  314. elsif ($self->{value} =~ /^r[\d]+d$/i) { $ret="l"; }
  315. elsif ($self->{value} =~ /^r[\w]+$/i) { $ret="q"; }
  316. elsif ($self->{value} =~ /^[a-d][hl]$/i){ $ret="b"; }
  317. elsif ($self->{value} =~ /^[\w]{2}l$/i) { $ret="b"; }
  318. elsif ($self->{value} =~ /^[\w]{2}$/i) { $ret="w"; }
  319. elsif ($self->{value} =~ /^e[a-z]{2}$/i){ $ret="l"; }
  320. $ret;
  321. }
  322. sub out {
  323. my $self = shift;
  324. if ($gas) { sprintf "%s%%%s",$self->{asterisk},$self->{value}; }
  325. else { $self->{value}; }
  326. }
  327. }
  328. { package label; # pick up labels, which end with :
  329. sub re {
  330. my ($class, $line) = @_;
  331. my $self = {};
  332. my $ret;
  333. if ($$line =~ /(^[\.\w]+)\:/) {
  334. bless $self,$class;
  335. $self->{value} = $1;
  336. $ret = $self;
  337. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  338. $self->{value} =~ s/^\.L/$decor/;
  339. }
  340. $ret;
  341. }
  342. sub out {
  343. my $self = shift;
  344. if ($gas) {
  345. my $func = ($globals{$self->{value}} or $self->{value}) . ":";
  346. if ($win64 &&
  347. $current_function->{name} eq $self->{value} &&
  348. $current_function->{abi} eq "svr4") {
  349. $func .= "\n";
  350. $func .= " movq %rdi,8(%rsp)\n";
  351. $func .= " movq %rsi,16(%rsp)\n";
  352. $func .= " movq %rsp,%rax\n";
  353. $func .= "${decor}SEH_begin_$current_function->{name}:\n";
  354. my $narg = $current_function->{narg};
  355. $narg=6 if (!defined($narg));
  356. $func .= " movq %rcx,%rdi\n" if ($narg>0);
  357. $func .= " movq %rdx,%rsi\n" if ($narg>1);
  358. $func .= " movq %r8,%rdx\n" if ($narg>2);
  359. $func .= " movq %r9,%rcx\n" if ($narg>3);
  360. $func .= " movq 40(%rsp),%r8\n" if ($narg>4);
  361. $func .= " movq 48(%rsp),%r9\n" if ($narg>5);
  362. }
  363. $func;
  364. } elsif ($self->{value} ne "$current_function->{name}") {
  365. # Make all labels in masm global.
  366. $self->{value} .= ":" if ($masm);
  367. $self->{value} . ":";
  368. } elsif ($win64 && $current_function->{abi} eq "svr4") {
  369. my $func = "$current_function->{name}" .
  370. ($nasm ? ":" : "\tPROC $current_function->{scope}") .
  371. "\n";
  372. $func .= " mov QWORD$PTR\[8+rsp\],rdi\t;WIN64 prologue\n";
  373. $func .= " mov QWORD$PTR\[16+rsp\],rsi\n";
  374. $func .= " mov rax,rsp\n";
  375. $func .= "${decor}SEH_begin_$current_function->{name}:";
  376. $func .= ":" if ($masm);
  377. $func .= "\n";
  378. my $narg = $current_function->{narg};
  379. $narg=6 if (!defined($narg));
  380. $func .= " mov rdi,rcx\n" if ($narg>0);
  381. $func .= " mov rsi,rdx\n" if ($narg>1);
  382. $func .= " mov rdx,r8\n" if ($narg>2);
  383. $func .= " mov rcx,r9\n" if ($narg>3);
  384. $func .= " mov r8,QWORD$PTR\[40+rsp\]\n" if ($narg>4);
  385. $func .= " mov r9,QWORD$PTR\[48+rsp\]\n" if ($narg>5);
  386. $func .= "\n";
  387. } else {
  388. "$current_function->{name}".
  389. ($nasm ? ":" : "\tPROC $current_function->{scope}");
  390. }
  391. }
  392. }
  393. { package expr; # pick up expressioins
  394. sub re {
  395. my ($class, $line, $opcode) = @_;
  396. my $self = {};
  397. my $ret;
  398. if ($$line =~ /(^[^,]+)/) {
  399. bless $self,$class;
  400. $self->{value} = $1;
  401. $ret = $self;
  402. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  403. $self->{value} =~ s/\@PLT// if (!$elf);
  404. $self->{value} =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
  405. $self->{value} =~ s/\.L/$decor/g;
  406. $self->{opcode} = $opcode;
  407. }
  408. $ret;
  409. }
  410. sub out {
  411. my $self = shift;
  412. if ($nasm && $self->{opcode}->mnemonic()=~m/^j(?![re]cxz)/) {
  413. "NEAR ".$self->{value};
  414. } else {
  415. $self->{value};
  416. }
  417. }
  418. }
  419. { package directive; # pick up directives, which start with .
  420. sub re {
  421. my ($class, $line) = @_;
  422. my $self = {};
  423. my $ret;
  424. my $dir;
  425. my %opcode = # lea 2f-1f(%rip),%dst; 1: nop; 2:
  426. ( "%rax"=>0x01058d48, "%rcx"=>0x010d8d48,
  427. "%rdx"=>0x01158d48, "%rbx"=>0x011d8d48,
  428. "%rsp"=>0x01258d48, "%rbp"=>0x012d8d48,
  429. "%rsi"=>0x01358d48, "%rdi"=>0x013d8d48,
  430. "%r8" =>0x01058d4c, "%r9" =>0x010d8d4c,
  431. "%r10"=>0x01158d4c, "%r11"=>0x011d8d4c,
  432. "%r12"=>0x01258d4c, "%r13"=>0x012d8d4c,
  433. "%r14"=>0x01358d4c, "%r15"=>0x013d8d4c );
  434. if ($$line =~ /^\s*(\.\w+)/) {
  435. bless $self,$class;
  436. $dir = $1;
  437. $ret = $self;
  438. undef $self->{value};
  439. $$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
  440. SWITCH: for ($dir) {
  441. /\.picmeup/ && do { if ($$line =~ /(%r[\w]+)/i) {
  442. $dir="\t.long";
  443. $$line=sprintf "0x%x,0x90000000",$opcode{$1};
  444. }
  445. last;
  446. };
  447. /\.global|\.globl|\.extern/
  448. && do { $globals{$$line} = $prefix . $$line;
  449. $$line = $globals{$$line} if ($prefix);
  450. last;
  451. };
  452. /\.type/ && do { my ($sym,$type,$narg) = split(',',$$line);
  453. if ($type eq "\@function") {
  454. undef $current_function;
  455. $current_function->{name} = $sym;
  456. $current_function->{abi} = "svr4";
  457. $current_function->{narg} = $narg;
  458. $current_function->{scope} = defined($globals{$sym})?"PUBLIC":"PRIVATE";
  459. } elsif ($type eq "\@abi-omnipotent") {
  460. undef $current_function;
  461. $current_function->{name} = $sym;
  462. $current_function->{scope} = defined($globals{$sym})?"PUBLIC":"PRIVATE";
  463. }
  464. $$line =~ s/\@abi\-omnipotent/\@function/;
  465. $$line =~ s/\@function.*/\@function/;
  466. last;
  467. };
  468. /\.asciz/ && do { if ($$line =~ /^"(.*)"$/) {
  469. $dir = ".byte";
  470. $$line = join(",",unpack("C*",$1),0);
  471. }
  472. last;
  473. };
  474. /\.rva|\.long|\.quad/
  475. && do { $$line =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
  476. $$line =~ s/\.L/$decor/g;
  477. last;
  478. };
  479. }
  480. if ($gas) {
  481. $self->{value} = $dir . "\t" . $$line;
  482. if ($dir =~ /\.extern/) {
  483. if ($flavour eq "elf") {
  484. $self->{value} .= "\n.hidden $$line";
  485. } else {
  486. $self->{value} = "";
  487. }
  488. } elsif (!$elf && $dir =~ /\.type/) {
  489. $self->{value} = "";
  490. $self->{value} = ".def\t" . ($globals{$1} or $1) . ";\t" .
  491. (defined($globals{$1})?".scl 2;":".scl 3;") .
  492. "\t.type 32;\t.endef"
  493. if ($win64 && $$line =~ /([^,]+),\@function/);
  494. } elsif (!$elf && $dir =~ /\.size/) {
  495. $self->{value} = "";
  496. if (defined($current_function)) {
  497. $self->{value} .= "${decor}SEH_end_$current_function->{name}:"
  498. if ($win64 && $current_function->{abi} eq "svr4");
  499. undef $current_function;
  500. }
  501. } elsif (!$elf && $dir =~ /\.align/) {
  502. $self->{value} = ".p2align\t" . (log($$line)/log(2));
  503. } elsif ($dir eq ".section") {
  504. $current_segment=$$line;
  505. if (!$elf && $current_segment eq ".init") {
  506. if ($flavour eq "macosx") { $self->{value} = ".mod_init_func"; }
  507. elsif ($flavour eq "mingw64") { $self->{value} = ".section\t.ctors"; }
  508. }
  509. } elsif ($dir =~ /\.(text|data)/) {
  510. $current_segment=".$1";
  511. } elsif ($dir =~ /\.global|\.globl|\.extern/) {
  512. if ($flavour eq "macosx") {
  513. $self->{value} .= "\n.private_extern $$line";
  514. } else {
  515. $self->{value} .= "\n.hidden $$line";
  516. }
  517. } elsif ($dir =~ /\.hidden/) {
  518. if ($flavour eq "macosx") { $self->{value} = ".private_extern\t$prefix$$line"; }
  519. elsif ($flavour eq "mingw64") { $self->{value} = ""; }
  520. } elsif ($dir =~ /\.comm/) {
  521. $self->{value} = "$dir\t$prefix$$line";
  522. $self->{value} =~ s|,([0-9]+),([0-9]+)$|",$1,".log($2)/log(2)|e if ($flavour eq "macosx");
  523. }
  524. $$line = "";
  525. return $self;
  526. }
  527. # non-gas case or nasm/masm
  528. SWITCH: for ($dir) {
  529. /\.text/ && do { my $v=undef;
  530. if ($nasm) {
  531. $v="section .text code align=64\n";
  532. } else {
  533. $v="$current_segment\tENDS\n" if ($current_segment);
  534. $current_segment = ".text\$";
  535. $v.="$current_segment\tSEGMENT ";
  536. $v.=$masm>=$masmref ? "ALIGN(256)" : "PAGE";
  537. $v.=" 'CODE'";
  538. }
  539. $self->{value} = $v;
  540. last;
  541. };
  542. /\.data/ && do { my $v=undef;
  543. if ($nasm) {
  544. $v="section .data data align=8\n";
  545. } else {
  546. $v="$current_segment\tENDS\n" if ($current_segment);
  547. $current_segment = "_DATA";
  548. $v.="$current_segment\tSEGMENT";
  549. }
  550. $self->{value} = $v;
  551. last;
  552. };
  553. /\.section/ && do { my $v=undef;
  554. $$line =~ s/([^,]*).*/$1/;
  555. $$line = ".CRT\$XCU" if ($$line eq ".init");
  556. if ($nasm) {
  557. $v="section $$line";
  558. if ($$line=~/\.([px])data/) {
  559. $v.=" rdata align=";
  560. $v.=$1 eq "p"? 4 : 8;
  561. } elsif ($$line=~/\.CRT\$/i) {
  562. $v.=" rdata align=8";
  563. }
  564. } else {
  565. $v="$current_segment\tENDS\n" if ($current_segment);
  566. $v.="$$line\tSEGMENT";
  567. if ($$line=~/\.([px])data/) {
  568. $v.=" READONLY";
  569. $v.=" ALIGN(".($1 eq "p" ? 4 : 8).")" if ($masm>=$masmref);
  570. } elsif ($$line=~/\.CRT\$/i) {
  571. $v.=" READONLY ";
  572. $v.=$masm>=$masmref ? "ALIGN(8)" : "DWORD";
  573. }
  574. }
  575. $current_segment = $$line;
  576. $self->{value} = $v;
  577. last;
  578. };
  579. /\.extern/ && do { $self->{value} = "EXTERN\t".$$line;
  580. $self->{value} .= ":NEAR" if ($masm);
  581. last;
  582. };
  583. /\.globl|.global/
  584. && do { $self->{value} = $masm?"PUBLIC":"global";
  585. $self->{value} .= "\t".$$line;
  586. last;
  587. };
  588. /\.size/ && do { if (defined($current_function)) {
  589. undef $self->{value};
  590. if ($current_function->{abi} eq "svr4") {
  591. $self->{value}="${decor}SEH_end_$current_function->{name}:";
  592. $self->{value}.=":\n" if($masm);
  593. }
  594. $self->{value}.="$current_function->{name}\tENDP" if($masm && $current_function->{name});
  595. undef $current_function;
  596. }
  597. last;
  598. };
  599. /\.align/ && do { my $max = ($masm && $masm>=$masmref) ? 256 : 4096;
  600. $self->{value} = "ALIGN\t".($$line>$max?$max:$$line);
  601. last;
  602. };
  603. /\.(value|long|rva|quad)/
  604. && do { my $sz = substr($1,0,1);
  605. my @arr = split(/,\s*/,$$line);
  606. my $last = pop(@arr);
  607. my $conv = sub { my $var=shift;
  608. $var=~s/^(0b[0-1]+)/oct($1)/eig;
  609. $var=~s/^0x([0-9a-f]+)/0$1h/ig if ($masm);
  610. if ($sz eq "D" && ($current_segment=~/.[px]data/ || $dir eq ".rva"))
  611. { $var=~s/([_a-z\$\@][_a-z0-9\$\@]*)/$nasm?"$1 wrt ..imagebase":"imagerel $1"/egi; }
  612. $var;
  613. };
  614. $sz =~ tr/bvlrq/BWDDQ/;
  615. $self->{value} = "\tD$sz\t";
  616. for (@arr) { $self->{value} .= &$conv($_).","; }
  617. $self->{value} .= &$conv($last);
  618. last;
  619. };
  620. /\.byte/ && do { my @str=split(/,\s*/,$$line);
  621. map(s/(0b[0-1]+)/oct($1)/eig,@str);
  622. map(s/0x([0-9a-f]+)/0$1h/ig,@str) if ($masm);
  623. while ($#str>15) {
  624. $self->{value}.="DB\t"
  625. .join(",",@str[0..15])."\n";
  626. foreach (0..15) { shift @str; }
  627. }
  628. $self->{value}.="DB\t"
  629. .join(",",@str) if (@str);
  630. last;
  631. };
  632. /\.comm/ && do { my @str=split(/,\s*/,$$line);
  633. my $v=undef;
  634. if ($nasm) {
  635. $v.="common $prefix@str[0] @str[1]";
  636. } else {
  637. $v="$current_segment\tENDS\n" if ($current_segment);
  638. $current_segment = "_DATA";
  639. $v.="$current_segment\tSEGMENT\n";
  640. $v.="COMM @str[0]:DWORD:".@str[1]/4;
  641. }
  642. $self->{value} = $v;
  643. last;
  644. };
  645. }
  646. $$line = "";
  647. }
  648. $ret;
  649. }
  650. sub out {
  651. my $self = shift;
  652. $self->{value};
  653. }
  654. }
  655. sub rex {
  656. my $opcode=shift;
  657. my ($dst,$src,$rex)=@_;
  658. $rex|=0x04 if($dst>=8);
  659. $rex|=0x01 if($src>=8);
  660. push @$opcode,($rex|0x40) if ($rex);
  661. }
  662. # Upon initial x86_64 introduction SSE>2 extensions were not introduced
  663. # yet. In order not to be bothered by tracing exact assembler versions,
  664. # but at the same time to provide a bare security minimum of AES-NI, we
  665. # hard-code some instructions. Extensions past AES-NI on the other hand
  666. # are traced by examining assembler version in individual perlasm
  667. # modules...
  668. my %regrm = ( "%eax"=>0, "%ecx"=>1, "%edx"=>2, "%ebx"=>3,
  669. "%esp"=>4, "%ebp"=>5, "%esi"=>6, "%edi"=>7 );
  670. my $movq = sub { # elderly gas can't handle inter-register movq
  671. my $arg = shift;
  672. my @opcode=(0x66);
  673. if ($arg =~ /%xmm([0-9]+),\s*%r(\w+)/) {
  674. my ($src,$dst)=($1,$2);
  675. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  676. rex(\@opcode,$src,$dst,0x8);
  677. push @opcode,0x0f,0x7e;
  678. push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
  679. @opcode;
  680. } elsif ($arg =~ /%r(\w+),\s*%xmm([0-9]+)/) {
  681. my ($src,$dst)=($2,$1);
  682. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  683. rex(\@opcode,$src,$dst,0x8);
  684. push @opcode,0x0f,0x6e;
  685. push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
  686. @opcode;
  687. } else {
  688. ();
  689. }
  690. };
  691. my $pextrd = sub {
  692. if (shift =~ /\$([0-9]+),\s*%xmm([0-9]+),\s*(%\w+)/) {
  693. my @opcode=(0x66);
  694. my $imm=$1;
  695. my $src=$2;
  696. my $dst=$3;
  697. if ($dst =~ /%r([0-9]+)d/) { $dst = $1; }
  698. elsif ($dst =~ /%e/) { $dst = $regrm{$dst}; }
  699. rex(\@opcode,$src,$dst);
  700. push @opcode,0x0f,0x3a,0x16;
  701. push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
  702. push @opcode,$imm;
  703. @opcode;
  704. } else {
  705. ();
  706. }
  707. };
  708. my $pinsrd = sub {
  709. if (shift =~ /\$([0-9]+),\s*(%\w+),\s*%xmm([0-9]+)/) {
  710. my @opcode=(0x66);
  711. my $imm=$1;
  712. my $src=$2;
  713. my $dst=$3;
  714. if ($src =~ /%r([0-9]+)/) { $src = $1; }
  715. elsif ($src =~ /%e/) { $src = $regrm{$src}; }
  716. rex(\@opcode,$dst,$src);
  717. push @opcode,0x0f,0x3a,0x22;
  718. push @opcode,0xc0|(($dst&7)<<3)|($src&7); # ModR/M
  719. push @opcode,$imm;
  720. @opcode;
  721. } else {
  722. ();
  723. }
  724. };
  725. my $pshufb = sub {
  726. if (shift =~ /%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  727. my @opcode=(0x66);
  728. rex(\@opcode,$2,$1);
  729. push @opcode,0x0f,0x38,0x00;
  730. push @opcode,0xc0|($1&7)|(($2&7)<<3); # ModR/M
  731. @opcode;
  732. } else {
  733. ();
  734. }
  735. };
  736. my $palignr = sub {
  737. if (shift =~ /\$([0-9]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  738. my @opcode=(0x66);
  739. rex(\@opcode,$3,$2);
  740. push @opcode,0x0f,0x3a,0x0f;
  741. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  742. push @opcode,$1;
  743. @opcode;
  744. } else {
  745. ();
  746. }
  747. };
  748. my $pclmulqdq = sub {
  749. if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  750. my @opcode=(0x66);
  751. rex(\@opcode,$3,$2);
  752. push @opcode,0x0f,0x3a,0x44;
  753. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  754. my $c=$1;
  755. push @opcode,$c=~/^0/?oct($c):$c;
  756. @opcode;
  757. } else {
  758. ();
  759. }
  760. };
  761. my $rdrand = sub {
  762. if (shift =~ /%[er](\w+)/) {
  763. my @opcode=();
  764. my $dst=$1;
  765. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  766. rex(\@opcode,0,$1,8);
  767. push @opcode,0x0f,0xc7,0xf0|($dst&7);
  768. @opcode;
  769. } else {
  770. ();
  771. }
  772. };
  773. my $rdseed = sub {
  774. if (shift =~ /%[er](\w+)/) {
  775. my @opcode=();
  776. my $dst=$1;
  777. if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
  778. rex(\@opcode,0,$1,8);
  779. push @opcode,0x0f,0xc7,0xf8|($dst&7);
  780. @opcode;
  781. } else {
  782. ();
  783. }
  784. };
  785. sub rxb {
  786. my $opcode=shift;
  787. my ($dst,$src1,$src2,$rxb)=@_;
  788. $rxb|=0x7<<5;
  789. $rxb&=~(0x04<<5) if($dst>=8);
  790. $rxb&=~(0x01<<5) if($src1>=8);
  791. $rxb&=~(0x02<<5) if($src2>=8);
  792. push @$opcode,$rxb;
  793. }
  794. my $vprotd = sub {
  795. if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  796. my @opcode=(0x8f);
  797. rxb(\@opcode,$3,$2,-1,0x08);
  798. push @opcode,0x78,0xc2;
  799. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  800. my $c=$1;
  801. push @opcode,$c=~/^0/?oct($c):$c;
  802. @opcode;
  803. } else {
  804. ();
  805. }
  806. };
  807. my $vprotq = sub {
  808. if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
  809. my @opcode=(0x8f);
  810. rxb(\@opcode,$3,$2,-1,0x08);
  811. push @opcode,0x78,0xc3;
  812. push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
  813. my $c=$1;
  814. push @opcode,$c=~/^0/?oct($c):$c;
  815. @opcode;
  816. } else {
  817. ();
  818. }
  819. };
  820. my $endbranch = sub {
  821. (0xf3,0x0f,0x1e,0xfa);
  822. };
  823. if ($nasm) {
  824. print <<___;
  825. default rel
  826. %define XMMWORD
  827. %define YMMWORD
  828. %define ZMMWORD
  829. ___
  830. } elsif ($masm) {
  831. print <<___;
  832. OPTION DOTNAME
  833. ___
  834. }
  835. print STDOUT "#if defined(__x86_64__)\n" if ($gas);
  836. while(defined(my $line=<>)) {
  837. $line =~ s|\R$||; # Better chomp
  838. $line =~ s|[#!].*$||; # get rid of asm-style comments...
  839. $line =~ s|/\*.*\*/||; # ... and C-style comments...
  840. $line =~ s|^\s+||; # ... and skip white spaces in beginning
  841. $line =~ s|\s+$||; # ... and at the end
  842. if (my $label=label->re(\$line)) { print $label->out(); }
  843. if (my $directive=directive->re(\$line)) {
  844. printf "%s",$directive->out();
  845. } elsif (my $opcode=opcode->re(\$line)) {
  846. my $asm = eval("\$".$opcode->mnemonic());
  847. if ((ref($asm) eq 'CODE') && scalar(my @bytes=&$asm($line))) {
  848. print $gas?".byte\t":"DB\t",join(',',@bytes),"\n";
  849. next;
  850. }
  851. my @args;
  852. ARGUMENT: while (1) {
  853. my $arg;
  854. ($arg=register->re(\$line, $opcode))||
  855. ($arg=const->re(\$line)) ||
  856. ($arg=ea->re(\$line, $opcode)) ||
  857. ($arg=expr->re(\$line, $opcode)) ||
  858. last ARGUMENT;
  859. push @args,$arg;
  860. last ARGUMENT if ($line !~ /^,/);
  861. $line =~ s/^,\s*//;
  862. } # ARGUMENT:
  863. if ($#args>=0) {
  864. my $insn;
  865. my $sz=$opcode->size();
  866. if ($gas) {
  867. $insn = $opcode->out($#args>=1?$args[$#args]->size():$sz);
  868. @args = map($_->out($sz),@args);
  869. printf "\t%s\t%s",$insn,join(",",@args);
  870. } else {
  871. $insn = $opcode->out();
  872. foreach (@args) {
  873. my $arg = $_->out();
  874. # $insn.=$sz compensates for movq, pinsrw, ...
  875. if ($arg =~ /^xmm[0-9]+$/) { $insn.=$sz; $sz="x" if(!$sz); last; }
  876. if ($arg =~ /^ymm[0-9]+$/) { $insn.=$sz; $sz="y" if(!$sz); last; }
  877. if ($arg =~ /^zmm[0-9]+$/) { $insn.=$sz; $sz="z" if(!$sz); last; }
  878. if ($arg =~ /^mm[0-9]+$/) { $insn.=$sz; $sz="q" if(!$sz); last; }
  879. }
  880. @args = reverse(@args);
  881. undef $sz if ($nasm && $opcode->mnemonic() eq "lea");
  882. if ($insn eq "movq" && $#args == 1 && $args[0]->out($sz) eq "xmm0" && $args[1]->out($sz) eq "rax") {
  883. # I have no clue why MASM can't parse this instruction.
  884. printf "DB 66h, 48h, 0fh, 6eh, 0c0h";
  885. } else {
  886. printf "\t%s\t%s",$insn,join(",",map($_->out($sz),@args));
  887. }
  888. }
  889. } else {
  890. printf "\t%s",$opcode->out();
  891. }
  892. }
  893. print $line,"\n";
  894. }
  895. print "\n$current_segment\tENDS\n" if ($current_segment && $masm);
  896. print "END\n" if ($masm);
  897. print "#endif\n" if ($gas);
  898. close STDOUT;
  899. #################################################
  900. # Cross-reference x86_64 ABI "card"
  901. #
  902. # Unix Win64
  903. # %rax * *
  904. # %rbx - -
  905. # %rcx #4 #1
  906. # %rdx #3 #2
  907. # %rsi #2 -
  908. # %rdi #1 -
  909. # %rbp - -
  910. # %rsp - -
  911. # %r8 #5 #3
  912. # %r9 #6 #4
  913. # %r10 * *
  914. # %r11 * *
  915. # %r12 - -
  916. # %r13 - -
  917. # %r14 - -
  918. # %r15 - -
  919. #
  920. # (*) volatile register
  921. # (-) preserved by callee
  922. # (#) Nth argument, volatile
  923. #
  924. # In Unix terms top of stack is argument transfer area for arguments
  925. # which could not be accommodated in registers. Or in other words 7th
  926. # [integer] argument resides at 8(%rsp) upon function entry point.
  927. # 128 bytes above %rsp constitute a "red zone" which is not touched
  928. # by signal handlers and can be used as temporal storage without
  929. # allocating a frame.
  930. #
  931. # In Win64 terms N*8 bytes on top of stack is argument transfer area,
  932. # which belongs to/can be overwritten by callee. N is the number of
  933. # arguments passed to callee, *but* not less than 4! This means that
  934. # upon function entry point 5th argument resides at 40(%rsp), as well
  935. # as that 32 bytes from 8(%rsp) can always be used as temporal
  936. # storage [without allocating a frame]. One can actually argue that
  937. # one can assume a "red zone" above stack pointer under Win64 as well.
  938. # Point is that at apparently no occasion Windows kernel would alter
  939. # the area above user stack pointer in true asynchronous manner...
  940. #
  941. # All the above means that if assembler programmer adheres to Unix
  942. # register and stack layout, but disregards the "red zone" existense,
  943. # it's possible to use following prologue and epilogue to "gear" from
  944. # Unix to Win64 ABI in leaf functions with not more than 6 arguments.
  945. #
  946. # omnipotent_function:
  947. # ifdef WIN64
  948. # movq %rdi,8(%rsp)
  949. # movq %rsi,16(%rsp)
  950. # movq %rcx,%rdi ; if 1st argument is actually present
  951. # movq %rdx,%rsi ; if 2nd argument is actually ...
  952. # movq %r8,%rdx ; if 3rd argument is ...
  953. # movq %r9,%rcx ; if 4th argument ...
  954. # movq 40(%rsp),%r8 ; if 5th ...
  955. # movq 48(%rsp),%r9 ; if 6th ...
  956. # endif
  957. # ...
  958. # ifdef WIN64
  959. # movq 8(%rsp),%rdi
  960. # movq 16(%rsp),%rsi
  961. # endif
  962. # ret
  963. #
  964. #################################################
  965. # Win64 SEH, Structured Exception Handling.
  966. #
  967. # Unlike on Unix systems(*) lack of Win64 stack unwinding information
  968. # has undesired side-effect at run-time: if an exception is raised in
  969. # assembler subroutine such as those in question (basically we're
  970. # referring to segmentation violations caused by malformed input
  971. # parameters), the application is briskly terminated without invoking
  972. # any exception handlers, most notably without generating memory dump
  973. # or any user notification whatsoever. This poses a problem. It's
  974. # possible to address it by registering custom language-specific
  975. # handler that would restore processor context to the state at
  976. # subroutine entry point and return "exception is not handled, keep
  977. # unwinding" code. Writing such handler can be a challenge... But it's
  978. # doable, though requires certain coding convention. Consider following
  979. # snippet:
  980. #
  981. # .type function,@function
  982. # function:
  983. # movq %rsp,%rax # copy rsp to volatile register
  984. # pushq %r15 # save non-volatile registers
  985. # pushq %rbx
  986. # pushq %rbp
  987. # movq %rsp,%r11
  988. # subq %rdi,%r11 # prepare [variable] stack frame
  989. # andq $-64,%r11
  990. # movq %rax,0(%r11) # check for exceptions
  991. # movq %r11,%rsp # allocate [variable] stack frame
  992. # movq %rax,0(%rsp) # save original rsp value
  993. # magic_point:
  994. # ...
  995. # movq 0(%rsp),%rcx # pull original rsp value
  996. # movq -24(%rcx),%rbp # restore non-volatile registers
  997. # movq -16(%rcx),%rbx
  998. # movq -8(%rcx),%r15
  999. # movq %rcx,%rsp # restore original rsp
  1000. # ret
  1001. # .size function,.-function
  1002. #
  1003. # The key is that up to magic_point copy of original rsp value remains
  1004. # in chosen volatile register and no non-volatile register, except for
  1005. # rsp, is modified. While past magic_point rsp remains constant till
  1006. # the very end of the function. In this case custom language-specific
  1007. # exception handler would look like this:
  1008. #
  1009. # EXCEPTION_DISPOSITION handler (EXCEPTION_RECORD *rec,ULONG64 frame,
  1010. # CONTEXT *context,DISPATCHER_CONTEXT *disp)
  1011. # { ULONG64 *rsp = (ULONG64 *)context->Rax;
  1012. # if (context->Rip >= magic_point)
  1013. # { rsp = ((ULONG64 **)context->Rsp)[0];
  1014. # context->Rbp = rsp[-3];
  1015. # context->Rbx = rsp[-2];
  1016. # context->R15 = rsp[-1];
  1017. # }
  1018. # context->Rsp = (ULONG64)rsp;
  1019. # context->Rdi = rsp[1];
  1020. # context->Rsi = rsp[2];
  1021. #
  1022. # memcpy (disp->ContextRecord,context,sizeof(CONTEXT));
  1023. # RtlVirtualUnwind(UNW_FLAG_NHANDLER,disp->ImageBase,
  1024. # dips->ControlPc,disp->FunctionEntry,disp->ContextRecord,
  1025. # &disp->HandlerData,&disp->EstablisherFrame,NULL);
  1026. # return ExceptionContinueSearch;
  1027. # }
  1028. #
  1029. # It's appropriate to implement this handler in assembler, directly in
  1030. # function's module. In order to do that one has to know members'
  1031. # offsets in CONTEXT and DISPATCHER_CONTEXT structures and some constant
  1032. # values. Here they are:
  1033. #
  1034. # CONTEXT.Rax 120
  1035. # CONTEXT.Rcx 128
  1036. # CONTEXT.Rdx 136
  1037. # CONTEXT.Rbx 144
  1038. # CONTEXT.Rsp 152
  1039. # CONTEXT.Rbp 160
  1040. # CONTEXT.Rsi 168
  1041. # CONTEXT.Rdi 176
  1042. # CONTEXT.R8 184
  1043. # CONTEXT.R9 192
  1044. # CONTEXT.R10 200
  1045. # CONTEXT.R11 208
  1046. # CONTEXT.R12 216
  1047. # CONTEXT.R13 224
  1048. # CONTEXT.R14 232
  1049. # CONTEXT.R15 240
  1050. # CONTEXT.Rip 248
  1051. # CONTEXT.Xmm6 512
  1052. # sizeof(CONTEXT) 1232
  1053. # DISPATCHER_CONTEXT.ControlPc 0
  1054. # DISPATCHER_CONTEXT.ImageBase 8
  1055. # DISPATCHER_CONTEXT.FunctionEntry 16
  1056. # DISPATCHER_CONTEXT.EstablisherFrame 24
  1057. # DISPATCHER_CONTEXT.TargetIp 32
  1058. # DISPATCHER_CONTEXT.ContextRecord 40
  1059. # DISPATCHER_CONTEXT.LanguageHandler 48
  1060. # DISPATCHER_CONTEXT.HandlerData 56
  1061. # UNW_FLAG_NHANDLER 0
  1062. # ExceptionContinueSearch 1
  1063. #
  1064. # In order to tie the handler to the function one has to compose
  1065. # couple of structures: one for .xdata segment and one for .pdata.
  1066. #
  1067. # UNWIND_INFO structure for .xdata segment would be
  1068. #
  1069. # function_unwind_info:
  1070. # .byte 9,0,0,0
  1071. # .rva handler
  1072. #
  1073. # This structure designates exception handler for a function with
  1074. # zero-length prologue, no stack frame or frame register.
  1075. #
  1076. # To facilitate composing of .pdata structures, auto-generated "gear"
  1077. # prologue copies rsp value to rax and denotes next instruction with
  1078. # .LSEH_begin_{function_name} label. This essentially defines the SEH
  1079. # styling rule mentioned in the beginning. Position of this label is
  1080. # chosen in such manner that possible exceptions raised in the "gear"
  1081. # prologue would be accounted to caller and unwound from latter's frame.
  1082. # End of function is marked with respective .LSEH_end_{function_name}
  1083. # label. To summarize, .pdata segment would contain
  1084. #
  1085. # .rva .LSEH_begin_function
  1086. # .rva .LSEH_end_function
  1087. # .rva function_unwind_info
  1088. #
  1089. # Reference to function_unwind_info from .xdata segment is the anchor.
  1090. # In case you wonder why references are 32-bit .rvas and not 64-bit
  1091. # .quads. References put into these two segments are required to be
  1092. # *relative* to the base address of the current binary module, a.k.a.
  1093. # image base. No Win64 module, be it .exe or .dll, can be larger than
  1094. # 2GB and thus such relative references can be and are accommodated in
  1095. # 32 bits.
  1096. #
  1097. # Having reviewed the example function code, one can argue that "movq
  1098. # %rsp,%rax" above is redundant. It is not! Keep in mind that on Unix
  1099. # rax would contain an undefined value. If this "offends" you, use
  1100. # another register and refrain from modifying rax till magic_point is
  1101. # reached, i.e. as if it was a non-volatile register. If more registers
  1102. # are required prior [variable] frame setup is completed, note that
  1103. # nobody says that you can have only one "magic point." You can
  1104. # "liberate" non-volatile registers by denoting last stack off-load
  1105. # instruction and reflecting it in finer grade unwind logic in handler.
  1106. # After all, isn't it why it's called *language-specific* handler...
  1107. #
  1108. # Attentive reader can notice that exceptions would be mishandled in
  1109. # auto-generated "gear" epilogue. Well, exception effectively can't
  1110. # occur there, because if memory area used by it was subject to
  1111. # segmentation violation, then it would be raised upon call to the
  1112. # function (and as already mentioned be accounted to caller, which is
  1113. # not a problem). If you're still not comfortable, then define tail
  1114. # "magic point" just prior ret instruction and have handler treat it...
  1115. #
  1116. # (*) Note that we're talking about run-time, not debug-time. Lack of
  1117. # unwind information makes debugging hard on both Windows and
  1118. # Unix. "Unlike" referes to the fact that on Unix signal handler
  1119. # will always be invoked, core dumped and appropriate exit code
  1120. # returned to parent (for user notification).