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.

[参考译文] MSP430F5529:PUSHX.W 指令不能正常工作

Guru**** 2862450 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/959123/msp430f5529-pushx-w-instruction-not-working-properly

器件型号:MSP430F5529

大家好、

我想报告一个使用 MSP430 Launchpad 套件时发现的问题。 我注意到 CPU 如何使用具有20位地址的绝对模式来正确识别 PUSHX.W 指令。 具体而言、使用指令"PUSHX[.W]&0x10000"、或者任何高于"0xFFF"的其他值、只需让 CPU 将值推入指定地址、同时其最重要的位被丢弃。 CPU 丢弃最重要的位、该位在扩展字中正确编码、并将其忽略。  "PUSHX[.W]&0x10000"将变为"PUSHX[.W]&0x0000"、"PUSHX[.W]&0x10010"将变为"PUSHX[.W]&0x0010"、"PUSHX[.W]&0x20333"将变为"PUSHX[.03W"。

值得注意的是、编译器正确区分了"PUSHX[.W]&0x10000"和"PUSHX[.W]&0x0000"、因为它使用扩展字来编码额外的位并使用不同的指令创建一个二进制代码、但是 CPU 对这两个指令没有做任何区分。  

如果有人对此问题有解决方案、我会感谢您的任何反馈!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我在汇编器中使用20位指令/寄存器、没有发现任何问题。

    PUSHX.B字节放置在堆栈上、PUSHX.W16位字放置在堆栈上。 PUSHX.A把20位字放在堆栈上。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    为什么要将大于20位的值入栈?

    MSP430无法识别大于20位的地址。

    伊斯天

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    答复似乎缺少这一点。 这看起来与 PUSHX 的 CPUx 指南中的示例完全相同:

    将字节保存在堆栈上的20位地址&EDE 上
    PUSHX.B &EDE;在地址 EDE 上保存字节

    他说、CPU 不使用20位地址&E 来获取参数、而是忽略地址的高4位。 压入堆栈的大小没有问题。

    我尝试使用气体为这种情况构建一个简单的测试用例、但它不能很好地工作。 当我写"pushx.w   &0x10000"时、objdump 将其呈现为:

    36:C0 18 12 pushx.w &0x0000 ;
    3a:00 

    扩展字中似乎有额外的地址位。 (0x18c0)

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 David:

    感谢您指出我的错误。 我认为 Bruce 是对的。 以下是 UG 的说明。 PUSHX.B 只能用于将8位、16位源压入堆栈。

    伊斯天

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    正是这样、我要指出用作指针的地址中的问题、而不是被压入的实际值。 很高兴知道这不仅仅是我的问题。 希望有办法解决这个问题,尽管我对此有疑问。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我做了更多的测试、问题超出了 PUSHX。 objdump 对所有格式 II 指令(单个参数)表现出相同的失败。 它也发生在格式 I (双参数)指令 tstx.w EDE 上。 (这实际上是比较指令、但使用常数发生器得到一个零。)

    我用 "rcx.w &0x10202"进行了一个非常简单的测试、它改变了 PAOUT。 (在0x0202上)。 因此、objdump 似乎只有在与文档或规定的扩展字编码不匹配的意义上存在缺陷。 它与硬件是一致的。

    442E: C0 18 12 10 rcx.w &0x0202 ;
    4432: 02 02 

    这种严重的缺陷到目前为止还不会引起人们的注意,这似乎是一种奇怪的现象。 我只能假设没有 C 编译器使用这些具有此寻址模式的指令。