MASM 9.0 bug.
-
Member 4194593 wrote:
Don't tell me MS
OK I won't - you clearly know they are the only ones who can do anything about it. Not that they will...
Member 4194593 wrote:
don't ask why not
Can I ask why we shouldn't ask why not? And if not, can I ask why we shouldn't ask why we shouldn't ask why not?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
MS will not fix 9.0, they will tell me to buy a newer version, and that version will have new errors for me to find. I do not even want their Express versions for the same reason - new errors to discover. I just want to warn programmers to watch out for this hard to find error. Dave.
-
What is MASM? You sure it isn't SPASM?
There are only 10 types of people in the world, those who understand binary and those who don't.
Hmm, is it a mutation of a woodpecker gene?
-
Where should I post a MASM 9.0 bug. It caused a very hard to find error (did not crash). Don't tell me MS, and don't ask why not. Dave.
-
What is MASM? You sure it isn't SPASM?
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Where should I post a MASM 9.0 bug. It caused a very hard to find error (did not crash). Don't tell me MS, and don't ask why not. Dave.
I think you could've explained it by now. I built a component with MASM which calls op code
mov eax, [ebx]
When it executes the processor melts. Maybe something like that. Keep it interesting and we'll read it. :) Good luck.
-
I think you could've explained it by now. I built a component with MASM which calls op code
mov eax, [ebx]
When it executes the processor melts. Maybe something like that. Keep it interesting and we'll read it. :) Good luck.
Thank you for the invitation. Just a warning to all. I had a function which had always been working. I modified it to align a short loop (added ALIGN OWORD). The function fails to function correctly (did not cause an error - just bad results which caused other errors - quite difficult to determine just what was happening). The data was 8 DWORDS which were all 0 except most significant which was 40000000h, and I was subtracting a single DWORD with a value of 1. I expected to get 7 DWORDS of FFFFFFFFh and the most significant DWORD with 3FFFFFFFh:
This is the source code:
;*******************************************************************************
;
; SUB a LONG_NUMB value from another. This is a routine called to subtract a
; long number from another after all scaling and validations have been done.
;
; esi has the source OFFSET of the data.
; edi has the already scaled OFFSET of the destination data.
; ecx has the DWORD count to subtract.
;
; Returns nothing with edi pointing to the last word modified. Note that this
; may not be the highest DWORD in the destination if a short source is
; subtracted from a long destination and there are no borrows past the last
; DWORD in the destination or source. This is primarily a check for a size
; extension due to a final borrow.
;
;*******************************************************************************ALIGN OWORD
SUBIt PROC PRIVATE USES eax ebx esi
pushfd clc;
; subtract all the value DWORDS.
;
ALIGN OWORDDoAll:
mov ebx,[esi]
lea esi,[esi + (SIZEOF DWORD)]
sbb [edi],ebx
lea edi,[edi + (SIZEOF DWORD)]
dec ecx
jnz DoAll
jnc Exit
mov eax,0
;
; Propogate the borrow.
;
ALIGN OWORDAgain:
sbb [edi],eax
lea edi,[edi + (SIZEOF DWORD)]
jc Again
;
; Exit SUBIt, adjust the destination pointer to the last modified DWORD.
;
Exit:
sub edi,(SIZEOF DWORD)
popfd
test dTestZero,0
ret
SUBIt ENDPThis is the generated code from MASM 9.0 (Visual Studio "Disassembly" tab):
ALIGN OWORD
SUBIt PROC PRIVATE USES eax ebx esi
00404FC0 push eax
00404FC1 push ebx
00404FC2 push esipushfd00404FC3 pushfd
clc
00404FC4 clc
00404FC5 lea esp,[esp]
00404FCC lea esp,[esp]
;
; subtract all the value DWORDS.
;
ALIGN OWORDDoAl
-
Thank you for the invitation. Just a warning to all. I had a function which had always been working. I modified it to align a short loop (added ALIGN OWORD). The function fails to function correctly (did not cause an error - just bad results which caused other errors - quite difficult to determine just what was happening). The data was 8 DWORDS which were all 0 except most significant which was 40000000h, and I was subtracting a single DWORD with a value of 1. I expected to get 7 DWORDS of FFFFFFFFh and the most significant DWORD with 3FFFFFFFh:
This is the source code:
;*******************************************************************************
;
; SUB a LONG_NUMB value from another. This is a routine called to subtract a
; long number from another after all scaling and validations have been done.
;
; esi has the source OFFSET of the data.
; edi has the already scaled OFFSET of the destination data.
; ecx has the DWORD count to subtract.
;
; Returns nothing with edi pointing to the last word modified. Note that this
; may not be the highest DWORD in the destination if a short source is
; subtracted from a long destination and there are no borrows past the last
; DWORD in the destination or source. This is primarily a check for a size
; extension due to a final borrow.
;
;*******************************************************************************ALIGN OWORD
SUBIt PROC PRIVATE USES eax ebx esi
pushfd clc;
; subtract all the value DWORDS.
;
ALIGN OWORDDoAll:
mov ebx,[esi]
lea esi,[esi + (SIZEOF DWORD)]
sbb [edi],ebx
lea edi,[edi + (SIZEOF DWORD)]
dec ecx
jnz DoAll
jnc Exit
mov eax,0
;
; Propogate the borrow.
;
ALIGN OWORDAgain:
sbb [edi],eax
lea edi,[edi + (SIZEOF DWORD)]
jc Again
;
; Exit SUBIt, adjust the destination pointer to the last modified DWORD.
;
Exit:
sub edi,(SIZEOF DWORD)
popfd
test dTestZero,0
ret
SUBIt ENDPThis is the generated code from MASM 9.0 (Visual Studio "Disassembly" tab):
ALIGN OWORD
SUBIt PROC PRIVATE USES eax ebx esi
00404FC0 push eax
00404FC1 push ebx
00404FC2 push esipushfd00404FC3 pushfd
clc
00404FC4 clc
00404FC5 lea esp,[esp]
00404FCC lea esp,[esp]
;
; subtract all the value DWORDS.
;
ALIGN OWORDDoAl
Yes, add eax, 0 would reset the carry flag. Weird issue, but fortunately the fix is easy: don't align that loop. I know, it's common knowledge that loops should be aligned, and that used to help. But these days we have loop buffers and µop caches so it doesn't matter anymore, unless the loop is huge but then the effect is comparatively small.
-
Member 4194593 wrote:
Don't tell me MS
OK I won't - you clearly know they are the only ones who can do anything about it. Not that they will...
Member 4194593 wrote:
don't ask why not
Can I ask why we shouldn't ask why not? And if not, can I ask why we shouldn't ask why we shouldn't ask why not?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Yes, add eax, 0 would reset the carry flag. Weird issue, but fortunately the fix is easy: don't align that loop. I know, it's common knowledge that loops should be aligned, and that used to help. But these days we have loop buffers and µop caches so it doesn't matter anymore, unless the loop is huge but then the effect is comparatively small.
Well I'm glad you know what hell he's talking about because none of the rest of us do. I'm just gonna go crawl back into my JavaScript and PHP corner now...
Jeremy Falcon
-
What is MASM? You sure it isn't SPASM?
There are only 10 types of people in the world, those who understand binary and those who don't.
As far as it is not SPAM...
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Where should I post a MASM 9.0 bug. It caused a very hard to find error (did not crash). Don't tell me MS, and don't ask why not. Dave.
-
Have you been at the Kool Aid again Griff?
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
It's a PITA to chop and line up for snorting... :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
Isn't the best place to post a Microsoft bug to, Microsoft? You know it will never be fixed thus never closed. Remain there forever :)
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
Just think of the warm-and-fuzzy feeling you will get for submitting it to Microsoft. I know they are still going to look at all those reports I submitted with Windows 95 and thank me later.
My plan is to live forever ... so far so good
-
Just think of the warm-and-fuzzy feeling you will get for submitting it to Microsoft. I know they are still going to look at all those reports I submitted with Windows 95 and thank me later.
My plan is to live forever ... so far so good
My feeling exactly, I was an ORCAS beta tester. Dave.
-
Yes, add eax, 0 would reset the carry flag. Weird issue, but fortunately the fix is easy: don't align that loop. I know, it's common knowledge that loops should be aligned, and that used to help. But these days we have loop buffers and µop caches so it doesn't matter anymore, unless the loop is huge but then the effect is comparatively small.
Harold,
harold aptroot wrote:
so it doesn't matter anymore
I made some timing tests and it took 22% longer to execute an unaligned loop vs an aligned loop, and that was for a short count of loops needed to complete the job, and I had even longer counts I wanted to run. It does make a difference, align your loops! Dave.
-
Harold,
harold aptroot wrote:
so it doesn't matter anymore
I made some timing tests and it took 22% longer to execute an unaligned loop vs an aligned loop, and that was for a short count of loops needed to complete the job, and I had even longer counts I wanted to run. It does make a difference, align your loops! Dave.
Ok, show your tests then, and I'll show you mine, which showed no difference. I've tested all 16 different alignments using these
global cmp0
proc_frame cmp0
[endprolog]
mov ecx, -10000000
xor eax, eax
jmp _cmp0_loop
align 16_cmp0_loop:
add ecx, 1
jnz _cmp0_loop
ret
endproc_frame; etc
global cmp15
proc_frame cmp15
[endprolog]
mov ecx, -10000000
xor eax, eax
jmp _cmp15_loop
align 16
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
_cmp15_loop:
add ecx, 1
jnz _cmp15_loop
ret
endproc_frameMeasured over 100 runs, taking the minimum, they all take 10000000 cyles + change (function call overhead and so on). No consistent or significant differences.
-
Ok, show your tests then, and I'll show you mine, which showed no difference. I've tested all 16 different alignments using these
global cmp0
proc_frame cmp0
[endprolog]
mov ecx, -10000000
xor eax, eax
jmp _cmp0_loop
align 16_cmp0_loop:
add ecx, 1
jnz _cmp0_loop
ret
endproc_frame; etc
global cmp15
proc_frame cmp15
[endprolog]
mov ecx, -10000000
xor eax, eax
jmp _cmp15_loop
align 16
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
_cmp15_loop:
add ecx, 1
jnz _cmp15_loop
ret
endproc_frameMeasured over 100 runs, taking the minimum, they all take 10000000 cyles + change (function call overhead and so on). No consistent or significant differences.
Harold, Your code is not doing the same thing, it is decrementing a register. My code was propagateing a borrow through multiple DWORDS. My timing indicated that the aligned code took 3.57 seconds to loop 100,000,000 (one hundred million) times, and 4.36 seconds to loop the same number of times for the unaligned test. That indicates that it took 1.22% longer. In addition, The loop had to re-initialize all of the DWORDS with the correct data for each loop. The loop included this initialization for both the base time and also for the test time, thus the time increment was due to only the time increment for the unaligned loop, meaning that the % difference is really in the neighborhood of 44%. I will give you the timing differences and the code changes between the two tests. If you want to see the the execution time differences (visual studio "disassembly" tab, then just ask and I will include that also.
RSA-Test TimeSbbLoop - 100M*TEST32: 3.57
;
; Code from Masm 9.0 .lst file for aligned test.
;
C ;*******************************************************************************
C ;
C ; Timing test for alignment.
C ;
C ; esi has the source OFFSET of the data.
C ; edi has the already scaled OFFSET of the destination data.
C ; ecx has the DWORD count to subtract.
C ;
C ;*******************************************************************************
C ALIGN OWORD
00001AEE C .data
C
C ALIGN OWORD
00001AF0 00000020 [ C TestData DWORD 32 DUP (0) ; 128 BYTES, 8 xmm regs
00000000
]
C
00001B70 00000001 C TestDWORD DWORD 1
C
C ALIGN WORD
00001B74 0023 C WORD (LENGTHOF szTestCase - 1)
00001B76 52 53 41 2D 54 C szTestCase BYTE "RSA-Test TimeSbbLoop - 100M*TEST32:",0
65 73 74 20 54
69 6D 65 53 62
62 4C 6F 6F 70
20 2D 20 31 30
30 4D 2A 54 45
53 54 33 32 3A
00
C
000006A0 C .code
C
C ;
C ; Get start time.
C ;
000006A0 C Start:
000006A0 E8 000054BB C CALL GetStartTime
C ; jnz Exit
C ;
C ; Clear the clear regs.
C ;
000006A5 66| 0F EF C0 C pxor xmm0,xmm0
000006A9 66| 0F 6F C8 C movdqa xmm1,xmm0
000006AD 66| 0F 6F D0 C -
Harold, Your code is not doing the same thing, it is decrementing a register. My code was propagateing a borrow through multiple DWORDS. My timing indicated that the aligned code took 3.57 seconds to loop 100,000,000 (one hundred million) times, and 4.36 seconds to loop the same number of times for the unaligned test. That indicates that it took 1.22% longer. In addition, The loop had to re-initialize all of the DWORDS with the correct data for each loop. The loop included this initialization for both the base time and also for the test time, thus the time increment was due to only the time increment for the unaligned loop, meaning that the % difference is really in the neighborhood of 44%. I will give you the timing differences and the code changes between the two tests. If you want to see the the execution time differences (visual studio "disassembly" tab, then just ask and I will include that also.
RSA-Test TimeSbbLoop - 100M*TEST32: 3.57
;
; Code from Masm 9.0 .lst file for aligned test.
;
C ;*******************************************************************************
C ;
C ; Timing test for alignment.
C ;
C ; esi has the source OFFSET of the data.
C ; edi has the already scaled OFFSET of the destination data.
C ; ecx has the DWORD count to subtract.
C ;
C ;*******************************************************************************
C ALIGN OWORD
00001AEE C .data
C
C ALIGN OWORD
00001AF0 00000020 [ C TestData DWORD 32 DUP (0) ; 128 BYTES, 8 xmm regs
00000000
]
C
00001B70 00000001 C TestDWORD DWORD 1
C
C ALIGN WORD
00001B74 0023 C WORD (LENGTHOF szTestCase - 1)
00001B76 52 53 41 2D 54 C szTestCase BYTE "RSA-Test TimeSbbLoop - 100M*TEST32:",0
65 73 74 20 54
69 6D 65 53 62
62 4C 6F 6F 70
20 2D 20 31 30
30 4D 2A 54 45
53 54 33 32 3A
00
C
000006A0 C .code
C
C ;
C ; Get start time.
C ;
000006A0 C Start:
000006A0 E8 000054BB C CALL GetStartTime
C ; jnz Exit
C ;
C ; Clear the clear regs.
C ;
000006A5 66| 0F EF C0 C pxor xmm0,xmm0
000006A9 66| 0F 6F C8 C movdqa xmm1,xmm0
000006AD 66| 0F 6F D0 C -
Of course it's not doing the same thing, it's just testing the effect of alignment by itself. There is way too much shit here to be sure of anything.
Harold, My feelings exactly. I will use what I have and beware of any ALIGN in the code section except for the entry at PROC. I will insure that there is no entry to an aligned Label except by a jump or conditional jump. Dave.
