MASM中的一个BUG

[日立奔腾浪潮微软松下联想]

问题是由这个帖子引起的：http://topic.csdn.net/u/20080603/20/f29b821b-3e06-4dfe-8ffe-8d95fccf3fe3.html?seed=1550459827

为了查看masm输出的指令时钟周期数，我使用不同的汇编指示测试一个小程序，结果发现了一个masm的bug：
如果使用了.686指示，masm的输出lst文件中根本没有timing数，如果使用.686p指示，则输出的timing数字十分怪异，动辄数百，完全不符合实际。
测试了ml 6.13.7299、6.14.8444、7.10.3077都是如此。
大家可以验证一下，或者直接用masm中的hello.asm例子，在里面随便加几条指令就可以。

[litorat]

消灭0回复

[cnzdgs]

我只用6.11，最多写586。估计是结果小于1，不知道该什么显示了。
ml的timing值只是理论值，在586中大部分指令就都是1个周期了。现在的CPU速度很快，加上缓存和指令流的作用，很多时候指令都不到1个周期。

[日立奔腾浪潮微软松下联想]

你的意思是它输出的timing不是一条指令本身的执行时间，而是它在指令流中表现出来的等效执行时间（对程序的使用者所感觉到的时间）？
不过这似乎更不可能。
因为：如果这样的话，同一条指令在代码中的位置不同则timing可能不同，比如：
xor eax,ebx
xor ecx,edx
在pentium+的超标量架构中，第二条指令是可以与第一条指令并行的，那么第二条指令的timing应该输出0，但实际输出并非如此。

[日立奔腾浪潮微软松下联想]

这是一个错误的输出：

Microsoft (R) Macro Assembler Version 7.10.3077 06/09/08 16:52:51
hello.asm Page 1 - 1


.686p
.MODEL flat, stdcall

=-0000000B STD_OUTPUT_HANDLE EQU -11

GetStdHandle PROTO NEAR32 stdcall,
nStdHandle:DWORD

WriteFile PROTO NEAR32 stdcall,
hFile:DWORD, lpBuffer:NEAR32, nNumberOfBytesToWrite:DWORD,
lpNumberOfBytesWritten:NEAR32, lpOverlapped:NEAR32

ExitProcess PROTO NEAR32 stdcall,
dwExitCode:DWORD

.STACK 4096

00000000 .DATA

00000000 48 65 6C 6C 6F 2C 20 msg DB "Hello, world.", 13, 10
77 6F 72 6C 64
2E 0D 0A
0000000F 00000000 written DD 0
00000013 00000000 hStdOut DD 0

00000000 .CODE
00000000 _start:

00000000 83 D5 0A aad
00000002 517 0F BD C2 bsr eax,edx
00000005 517 8D 05 00000000 R lea eax,_start
0000000B 517 33 D2 xor edx,edx
0000000D 524p 85 0C 90 test [eax+edx*4],ecx
00000010 517 85 C1 test eax,ecx
00000012 645 A9 00000001 test eax,1
00000017 517 8D 04 95 lea eax,[edx*4+_start]
00000000 R
0000001E 517 8D 02 lea eax,[edx]

INVOKE GetStdHandle,
STD_OUTPUT_HANDLE ; Standard output handle
00000027 643p A3 00000013 R mov hStdOut, eax

INVOKE WriteFile,
hStdOut, ; File handle for screen
NEAR32 PTR msg, ; Address of string
LENGTHOF msg, ; Length of string
NEAR32 PTR written, ; Bytes written
0 ; Overlapped mode

INVOKE ExitProcess,
0 ; Result code for parent process

PUBLIC _start
END

...

[日立奔腾浪潮微软松下联想]

没人关注吗？:)

[xiang37]

学习中 不知道阿!

[大熊猫侯佩]

[Quote=引用 5 楼 DelphiGuy 的回复:]
没人关注吗？:)

[/Quote]
建议 DelphiGuy 老兄，跟踪编译过程 ，看看遇到 .686 时，masm 犯了什么病。

[用户 昵称]

从来不关心运行效率的人飘过。

[debugk]

俺还没有学到,帮顶一个

[dongyi940333]

俺还没有学到,帮顶一个

[yang709610485]

up,学习哈。。。虽然没看懂

[nickykou]

[Quote=引用 4 楼 DelphiGuy 的回复:]
这是一个错误的输出：

Microsoft (R) Macro Assembler Version 7.10.3077 06/09/08 16:52:51
hello.asm Page 1 - 1


.686p
.MODEL flat, stdcall

=-0000000B STD_OUTPUT_HANDLE EQU -11

GetStdHandle PROTO NEAR32 stdcall,
nStdHandle:DWORD

WriteFile PROTO NEAR32 stdcall,
hFile:DWORD, lpBuffer:NEAR32, nNumberOfBytesToWrite:DWORD,
…
[/Quote]
怎么输出错误了？

[日立奔腾浪潮微软松下联想]

错误之处在于指令的timing数，诸如517之类，完全夸张到离谱。
另外，超标量架构是可以真正在指令级并行的，注意是真正并行，多条指令确切地在同一个时刻开始执行。

[xujiie]

学习一下

[chpst]

个人观点，masm timing值只是个参考数据，是100%的准确，可能是个估值的
而且不全是软件的问题，也可能是硬件的缺陷； cpu 型号相同结果都可能不同。而且我对并行处理,始终认为到最后都是串行的。因为时钟不可能并行。

[fycom200]

好久没用 MASM 了

[嗷嗷叫的老马]

好久没来汇编版晃了.........帮顶......