此装配项目读取按键并以特定颜色输出。当按下元音时,它会改变文本的颜色,直到按下另一个元音,直到按下ESC键为止。颜色处于某种模式,这就是我在SUB 8到达循环结束时的原因。我只是想提高效率。我尝试将所有比较语句分成一行,但并不成功。
INCLUDE Macros.inc
INCLUDE Irvine32.inc
INCLUDELIB Irvine32.lib
.386
.STACK 4096
ExitProcess PROTO, dwExitCode:DWORD
.DATA
key BYTE ?
colorCode BYTE 5
max BYTE 13
.CODE
main PROC
FindKey:
mov EAX, 50
call Delay
call ReadKey
jz FindKey
MOV key, AL
cmp key, 75h
JE UP
CMP key, 6Fh
JE UP
CMP key, 69h
JE UP
CMP key, 65h
JE UP
CMP key, 61h
JE UP
CMP key, 55h
JE UP
CMP key, 4Fh
JE UP
CMP key, 49h
JE UP
CMP key, 45h
JE UP
CMP key, 41h
JE UP
CMP dx,VK_ESCAPE
JE OVER
COLOR:
MOVZX EAX, (black * 16) + colorCode
CALL SetTextColor
MOV AL, key
call WriteChar
jmp FindKey
UP:
CMP colorCode, 13
JE RESET
INC colorCode
jmp COLOR
RESET:
sub colorCode, 8
jmp COLOR
OVER:
CALL Crlf
INVOKE ExitProcess, 0
main ENDP
END main
答案 0 :(得分:4)
如果您对高效的x86代码感兴趣,请参阅x86标记wiki中的链接。有很多好东西,尤其是Agner Fog的指南。
key
中有AL
,但您的cmp
指令都使用内存操作数。 cmp al, imm8
有一个特殊的操作码,因此cmp al, 75h
只是一个2字节的指令。使用绝对位移来寻址key
会使多更长的指令。此外,cmp mem,imm
无法通过条件跳转进行宏融合。每个insn都需要加载端口。
其余的代码看起来很可疑,因为它过多地使用了内存操作数,并且缩进了很多。 (UP
看起来像COLOR
块的一部分,但实际上COLOR
结束时无条件跳转,所以它没有落入UP
。)
当然,由于所有cmp/je
目标都是相同的,所以je
很长的系列都不是最佳的。您不需要弄明白哪个键实际匹配。
al
是否在正确的范围内,然后将其用作位图的索引。 switch
or multi-condition if
like this。这就是为什么我们在大多数时候使用编译器而不是手动编写asm:他们知道许多聪明的技巧并且可以在适用的地方应用它们。
有关无符号比较技巧(ja .non_alphabetic
)的解释和有效循环的示例,请参阅my answer on another ASCII question。
MOV [key], AL ; store for later use
or al, 0x20 ; lowercase (assuming an alphabetic character)
sub al, 'a' ; turn the ascii encoding into an index into the alphabet
cmp al, 'z'
ja .non_alphabetic
mov ecx, 1<<('a'-'a') | 1<<('e'-a') | 1<<('i'-a') | 1<<('o'-a') | 1<<('u'-a') ; might be good to pull this constant out and use an EQU to define it
movzx eax, al
bt ecx, eax ; test for the letter being set in the bitmap
jc UP ; jump iff al was a vowel
.non_alphabetic:
CMP dx,VK_ESCAPE ; this test could be first.
JE OVER
这种指令明显减少,分支也少得多,因此它消耗的分支预测条目更少。
这可能不是严格合法的MASM语法; IDK,如果它具有0x
十六进制常量,就像NASM一样。我甚至没有让MASM尝试组装,而且我应该明白我的写作指示。 (编辑欢迎,如果有人想要制作这种有效的MASM语法。我知道你不需要围绕内存操作数的方括号,但它们是允许的,所以为了清楚起见我使用它们。)
不要将常量保留在bt
的内存中:bt
内存操作数很慢,因为疯狂的CISC语义可以访问不同的地址,因为位索引更高比操作数大小。当bt
与寄存器第一个操作数一起使用时,它只屏蔽位索引。
bt
的替代方法是if(mask & 1 << (key - 'a'))
:
movzx ecx, al ; avoid partial-reg stall or false dep on ecx that you could get with mov ecx,eax or mov cl,ca respectively
mov eax, 1
shl eax, cl ; eax has a single set bit, at the index
test eax, 1<<('a'-'a') | 1<<('e'-a') | 1<<('i'-a') | 1<<('o'-a') | 1<<('u'-a')
jnz .vowel
这是更多的uops,即使test / jnz可以进行宏熔丝,因为Intel CPU上的可变计数移位为3 uop。 (再次,疯狂的CISC语义会减慢速度。)
由于评论正在讨论SSE:
; broadcast the key to all positions of an xmm vector, and do a packed-compare against a constant
mov ah, al ; leads to a partial-reg stall on some CPUs :/
movzx eax, ax ; eax = 0 0 key key
movd xmm0, eax
pshufd xmm0, xmm0, 0 ; broadcast the low 32b element to all four 32b elements
pcmpeqb xmm0, [vowels] ; byte elements where key matches the mask are set to -1, others to 0
pmovmskb eax, xmm0
test eax,eax
jnz .vowel
section .rodata:
vowels: db 'a','A', 'a','A' ; the 0s in the upper two bytes of eax must not produce false positives, so use 'a','A' as filler for those bytes. -1 would work too
db 'e','E', 'a','A'
db 'i','I', 'a','A'
db 'o','O', 'a','A'
;; oops, no room for 'u' with this strategy. Fixing this is left as an exercise for the reader
字节广播(pshufb
)而不是双字广播(pshufd
)会这样做。 (或AVX2 vpbroadcastb
)。或者在广播之前使用or al,0x20
,因此我们不需要每个vower的大小写版本,只需要小写。
这需要从内存中加载一个常量,而不是在指令流中可以有效地立即生成的32位位图,所以即使它只有一个分支,这可能不太好。 (请记住,位图版本需要以非字母分支,然后是元音)。