This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好
我发现这个问题、这可能是对 MSP430FR2/FR4系列产品手册的误解。
但是、即使经过大量挖掘、似乎也无法找出问题所在。
它在系列手册 MPY32章节下的第16.2.2节中说、MACS 运算中的进位位(MPYC)反映了累积的进位。
但是、通过我的小型测试程序、我不知何故无法看到它。
我首先做了一个简单的带符号 MPYS 操作-6和5、得出了一个预期的-30的结果。
对于 MPYS 操作、进位位应设置为结果的符号、即结果的符号。 在这个情况下、MPYC 为1 (置位)。
但是、当后续进行-4 x -5的 MACS 运算时、应将乘以20的结果相加
与前一个结果(-30)进行比较以得到-10。 我得到的结果。 但是、令我吃惊的是、MPY32CTL0中的进位位(MPYC)被设定。
为什么?
由于我使用一个16x16乘法、先前的结果与新乘法的累加应该在32位中完成。
先前的结果是(-30、0xFFFF FFE2) 被添加到新的乘法(+20、0x14)中的确为-10 (0xFFFF FFF6)。
但是、这个和不会溢出32位(FFFF FFE2 + 0000 00014 = FFFF FFF6)、所以不应该设置进位?
我在这里误解了什么?
注1:使用完整的32x32位乘法时、我的确可以重现相同的效果。
注2:我的所有示例都可生成预期的 RESx 寄存器和 SUMEXT 寄存器、唯一的问题是
MACS 运算中的 MPYC 位。 所有其它的乘法运算类型给出一个与系列手册说明相匹配的 MPYC 位。
这是我运行的示例程序、它在最后一行(status = MPY32CTL0)给出一个 MPYC 位设置为1、当我的预期值为0时。
//开始示例代码:
int main (空)
{
volatile unsigned int i、j、status;
WDTCTL = WDTPW | WDTHOLD;//停止看门狗计时器
//某些测试乘法
MPYS = 0xFFFA;//-6
OP2 = 0x5;//+5 =>(-6)*(+5)=-30
___ no_operation();
I = RESLO;
J = RESHI;
状态= MPY32CTL0;
___ no_operation();
MACS = 0xFFFC;//-4
Op2 = 0xFFFB;//-5 =>(-4)*(-5)=+20总累加=>-30 + 20 =-10
___ no_operation();
I = RESLO;
J = RESHI;
状态= MPY32CTL0;
}
//结束示例代码
如果有人能在这里指出问题、请表示赞赏。
真诚的 布朗 熊
在我检查时、没有针对 MPY32的代码示例。 但是、如果使用 IQmath/Qmath、它将自动使用此外设。 您可以参考一下吗?
您是否阅读过 MACS 溢出在16.2.2.1处的手册? 由于您的示例没有溢出、因此 carry 将与符号相同。
您好! 谢谢您的建议。 我使用 一些任意宽度的数学库、此 IQmath 对于实现非常有帮助。
感谢您的帮助! 我不是100%肯定你会去,但你所说的触发了以下思维。 我将16.2.2.1最后一段解释为一个事实、即如果存在溢出或下溢、则 MPYC 和 SUMEXT 位是不同的(但、我假设 MPYC 仍反映累积的第32或第64位的算术进位位)。 但是、如果我猜您想说的话、您说在下溢/上溢的情况下、MPYC ON 的用途被设定为 SUMEXT 被设定的不同值、只是为了表示发生了下溢/上溢。 基本上、MPYC 位不再是一个纯进位位、它是一个针对下溢/上溢的进位与一个信令机制的组合? 我对你的答案的解释是对的吗? 如果原因如此、您的答案可以解决此问题。 然后、我将执行更多测试来检查它。
您好! 然后我在测试了许多其他例子后得出结论,这确实是正确的解释。 在 MACS 模式中、进位位(MPYC 位)与算术进位无关! 它仅表示上溢/下溢情况。 如果 SUMEXT 和 MPYC 不同意、则表示发生了下溢/上溢。