1. 問(wèn)題
在IOS系統(tǒng)下有這么兩個(gè)語(yǔ)句：
Arch64:
"fmla v16.4s, v14.4s, v0.4s \n"
v0 unsigned char __attribute__((ext_vector_type(16)))
(0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f)
v14 unsigned char __attribute__((ext_vector_type(16)))
(0x00, 0x30, 0x97, 0x42,
0x00, 0x00, 0x86, 0x40,
0x00, 0xc0, 0x16, 0x42,
0x00, 0xc0, 0x59, 0x42)
v16 unsigned char __attribute__((ext_vector_type(16)))
(0x00, 0x30, 0x97, 0x42,
0x00, 0x00, 0x86, 0x40,
0x00, 0xc0, 0x16, 0x42,
0x00, 0xc0, 0x59, 0x42)
v0跟v14乘加到v16上，但是v16的值卻跟v14一樣，為何？
Arch32:
"vmla.u32 q10, q2, q13 \n"
q13 unsigned char __attribute__((ext_vector_type(16)))
(0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f)
q2 unsigned char __attribute__((ext_vector_type(16)))
(0x00, 0x30, 0x97, 0x42,
0x00, 0x00, 0x86, 0x40,
0x00, 0xc0, 0x16, 0x42,
0x00, 0xc0, 0x59, 0x42)
q10 unsigned char __attribute__((ext_vector_type(16)))
(0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00)
q13跟q2乘加到q10，結(jié)果卻是全0，為何？
2. 分析
float特點(diǎn)
float計(jì)算
float2HEX python轉(zhuǎn)換接口
import struct
print struct.unpack('!f', '42f0e666'.decode('hex'))[0]
print hex(struct.unpack('<I', struct.pack('<f', 120.45))[0])
>>> 120.449996948
>>> 0x42f0e666
3. 結(jié)論
Arch64:
v10中的v10.s[0]:0x00, 0x00, 0x80, 0x3f,轉(zhuǎn)換成 HEX 就是 0x3f800000，對(duì)應(yīng)的bin值是：
0011 1111 1000 0000 0000 0000 0000 0000(32bit)
float計(jì)算就是這么算的(參考wiki)：
轉(zhuǎn)換例子：
[0]011 1111 1000 0000 0000 0000 0000 0000
符號(hào) sign = (-1)^0 = +1
0[011 1111 1]000 0000 0000 0000 0000 0000
指數(shù) exponent = (-127) + 127 = 0
0011 1111 1[000 0000 0000 0000 0000 0000]
尾數(shù) fraction = 1 + （0*2^-1 + 0*2^-2 + 0*2^-3 + ....）= 1.0
float value = (+1) * 1.0 * 2^0 = 1.0
因此v10中的全是1.0，乘以v14后累加到v16中當(dāng)然就是v14的浮點(diǎn)值咯！（ps. v16初始化為0了的）
注意：NEON寄存器中數(shù)據(jù)的順序低位在前，高位在后，在每個(gè)數(shù)據(jù)單元中高位在前低位在后，如上例所述。
Arch32:
q10之所以全為0，是因?yàn)?
#0x3f800000 * #0x42973000 = #0x1084 8068 [0000 0000]我們是以單精度也就是32bit來(lái)進(jìn)行運(yùn)算的，因此這里的結(jié)果值顯然是溢出了(需要64bit方能存儲(chǔ)完全)，對(duì)溢出的處理默認(rèn)是截取低32bit就好，這里的低32bit就剛好是0，因此就出現(xiàn)了兩個(gè)int值相乘結(jié)果為0的“假像”，背后的本質(zhì)就是值溢出，硬件截?cái)鄶?shù)值。
"mov w5, #0x0000 \n"
"movk w5, #0x3f80, LSL #16 \n"
// "mov w5, #0x3f800000 \n"
"mov v0.s[0], w5 \n"
"mov v0.s[1], w5 \n"
"mov v0.s[2], w5 \n"
"mov v0.s[3], w5 \n"
"mov w6, #0x3000 \n"
"movk w6, #0x4297, LSL #16 \n"
// "mov w6, #0x42973000 \n"
"mov v1.s[0], w6 \n"
"mov v1.s[1], w6 \n"
"mov v1.s[2], w6 \n"
"mov v1.s[3], w6 \n"
"eor v2.8b, v2.8b, v2.8b \n"
"mla v2.4s, v0.4s, v1.4s \n"
ps. 上述在Arch64下的mla等價(jià)于Arch32下的VMLA.u32
附錄·mov指令
mov的一些基本概念：
"mov w5, #0x3f800000 \n"
"mov v0.s[0], w5 \n"
"mov v0.s[1], w5 \n"
"mov v0.s[2], w5 \n"
"mov v0.s[3], w5 \n"
v0 (0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f,
0x00, 0x00, 0x80, 0x3f)
這是對(duì)的,也就是說(shuō)立即數(shù)搬運(yùn)只能是16bit寬度，你可以是上16bit也可以是下16bit，但是不能跨越；
"mov w5, #0x3f80 \n"
"mov v0.s[0], w5 \n"
"mov v0.s[1], w5 \n"
"mov v0.s[2], w5 \n"
"mov v0.s[3], w5 \n"
等價(jià)于0x00003f80，編譯器在前面自動(dòng)補(bǔ)零；
v0 (0x80, 0x3f, 0x00, 0x00,
0x80, 0x3f, 0x00, 0x00,
0x80, 0x3f, 0x00, 0x00,
0x80, 0x3f, 0x00, 0x00)
在數(shù)據(jù)手冊(cè)里面mov指令明確指示立即數(shù)只能是16bit大小的:
可以看到Operation區(qū)域說(shuō)了搬運(yùn)的只能是16bit的立即數(shù)，因此下面的這個(gè)#0x42973000超出范圍了（0x42970000則在范圍之內(nèi)，這里會(huì)被編譯器解釋為“高半字：0x4297），搬運(yùn)直接編譯就會(huì)報(bào)錯(cuò)的：
"mov w6, #0x42973000 \n"
現(xiàn)在的需求是我們要把32bit跟64bit的立即數(shù)搬運(yùn)到寄存器里面去，但是指令不支持，這個(gè)怎么整？
看下這個(gè)是A64下的通用指令集，有MOVN、MOVK、MOVZ是可以加移位操作的（ps.單純的mov指令是不可移位的哈，注意）；
這三個(gè)指令有什么區(qū)別呢？
- movn就是移位之后,整個(gè)w寄存器都反轉(zhuǎn)了；
"movn w6, #0x1, LSL #16 \n"
w6: 0xfffeffff
- movz就是移位之后置零,移出來(lái)的空位就置零了；
"movn w6, #0x1, LSL #16 \n"
w6: 0x00010000
- movk就是移出來(lái)的空位保持原樣；
這也就是說(shuō)我們先把低16bit立即數(shù)移動(dòng)到w寄存器，然后用movk的方式移動(dòng)高16bit就好啦！
"mov w6, #0x3000 \n" //先搬運(yùn)下半16bit；
"movk w6, #0x4297, LSL #16 \n" //搬運(yùn)上半16bit，同時(shí)不影響下半16bit；
w6: 0x42973000
