为何用mul.ss 而不用 mul.uu

2万 · 2021-9-8 22:56

128:             unsigned int iX=0x1234,iY=0x5678;
  0360  212342    mov.w #0x1234,0x0004
129:             unsigned long lZ;
130:
131:                         while(1)
132:                {       cAmpInv=lZ>>24;
  0364  DE0848    lsr 0x0002,#8,0x0000
  0366  B7E804    mov.b 0x0000,0x0804
133:                         ++iX,
  0368  E80102    inc.w 0x0004,0x0004
134:                         lZ=iX*iY;
  0362  256783    mov.w #0x5678,0x0006
  036A  B99003    mul.ss 0x0004,0x0006,0x0000
  036C  200001    mov.w #0x0,0x0002
  036E  37FFFA    bra 0x000364
申请了两个uint iX, iY. 将两个相乘后的结果存入 ulong变量lZ。

2万 · 2021-9-8 22:59

还有什么现象？能再详细描述下吗？

2万 · 2021-9-8 23:02

为何将积的高16位清零

2万 · 2021-9-8 23:04

你倒是说说mul.ss和 mul.uu有什么区别

1万 · 2021-9-8 23:05

没看出高16位清零

2万 · 2021-9-8 23:07

mul.ss和 mul.uu 分别用于有符号和无符号数相乘。

2万 · 2021-9-8 23:09

036C 200001 mov.w #0x0,0x0002 积低16位存放在0x0000，高16位放0x0002. 用立即数#0x0填充0x0002是什么意思？

1万 · 2021-9-8 23:11

也不是很理解。
不过这个你大概要手动提升类型才会得到想要的结果。

2万 · 2021-9-8 23:13

lZ=(unsigned long)iX*iY;

1万 · 2021-9-8 23:15

这就是一个类型提升的问题。 XC16认为等号的右边手动提升类型，所以计算结果的高字是没有用的

1万 · 2021-9-8 23:17

虽然最后结果赋值给了一个更高级别类型，但是不影响编译器对于右边部分的理解

1万 · 2021-9-8 23:40

这个在编译器的处理上是合理的，编译器要求用户做显式类型提升，而不是由编译器来做自动提升

2万 · 2021-9-8 23:42

C规范应该是没有强制要求提升，不过自动提升也许对用户更好些

2万 · 2021-9-8 23:44

其实还是不大明白，我再琢磨琢磨吧，多谢了哈先