MASM 9.0 bug.
-
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.
