MASM 9.0 bug.

Member 4194593

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.

OriginalGriff

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...

ZurdoDev

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.

Member 4194593

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.

Kenneth Haugland

Hmm, is it a mutation of a woodpecker gene?

Lost User

Member 4194593 wrote:

Don't tell me MS

Well, there's nowhere else of any use.

Member 4194593 wrote:

and don't ask why not

The answer's obvious.

Lost User

You joke, but there are at least 3 different assemblers actually named SPASM.

newton saber

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.

Member 4194593

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 OWORD

DoAll:
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 OWORD

Again:
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 ENDP

This 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 esi

pushfd

00404FC3 pushfd
clc
00404FC4 clc
00404FC5 lea esp,[esp]
00404FCC lea esp,[esp]
;
; subtract all the value DWORDS.
;
ALIGN OWORD

DoAl

Lost User

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.

PhilLenoir

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.

Jeremy Falcon

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

Nelek

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.

S Douglas

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.

OriginalGriff

It's a PITA to chop and line up for snorting... :laugh:

Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...

DJ van Wyk

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

Member 4194593

My feeling exactly, I was an ORCAS beta tester. Dave.

Member 4194593

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.

Lost User

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_frame

Measured over 100 runs, taking the minimum, they all take 10000000 cyles + change (function call overhead and so on). No consistent or significant differences.

Member 4194593

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