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.

[参考译文] 编译器/UCD3138:两个32位数据乘法结果不正确

Guru**** 674950 points
Other Parts Discussed in Thread: AM1808, UCD3138, UCD3138OL64EVM-031, TMS570LC4357
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/594508/compiler-ucd3138-two-32-bits-data-multiplication-result-is-not-correct

部件号:UCD3138
主题中讨论的其他部件:AM1808,,, TMS570LC4357,LAUNCXL2-570LC43

工具/软件:TI C/C++编译器

您好,

我正在将6.1 与编译器5.22 一起使用。 我发现两 个32位数据的乘法结果不正确。  我将结果定义为64位数据。正确的结果应为0x0000 0056 0038 7512。 我看到一 个寄存器R0 的号码是0x0000 0056,另一个寄存器R1的号码 是0x38.7512万,这是正确的。但是,我得到的结果是0x0038 7512 0000 0056,这似乎两个寄存器的数据被放置在错误的顺序中。

是错误还是我未正确配置CCS?

谢谢!

Julie

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

    代码为:

    UINT16 uint16_multiple_shift_clamp (UINT32 x,UINT32 y,Int16 SHIFT,UINT16 max_value)

    UINT64 scale product_64;

    scale product_64 =(UINT64) x*y;

    }

    我试图将变量scale product_64声明为全局变量,结果是正确的。  

    请参阅随附的文档。  我将所有屏幕截图都放入本文档中。  

    谢谢

    Juliee2e.ti.com/.../64_2D00_bits-multiplication.docx

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    问题是您是将x转换为uint64_t还是将x*y转换为uint64_t? 如果是后者,则乘法仍为32位。
    尝试((uint64_t) x)* y
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我很肯定这不是原因。

    首先,我对scale product_64被声明为全局变量的情况使用了相同的语句。结果是正确的。

    其次,我尝试了不同的方法,如scale_product_64 =((UINT64)x)*((UINT64)y);结果相同。

    但我知道这可能只是调试器内部显示的问题。 我认为显示屏上有一个错误,它将单词按错误的顺序排列。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    这是预期行为。  当64位整数值驻留在寄存器对中时,偶数寄存器保存高位,奇数寄存器保存低位。  检查64位值时,请避免查看寄存器。  很容易混淆。  查看监视窗口或类似内容。

    谢谢,此致,

    -George

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

    [引述用户="George mock"]

    这是预期行为。  当64位整数值驻留在寄存器对中时,偶数寄存器保存高位,奇数寄存器保存低位。  检查64位值时,请避免查看寄存器。  很容易混淆。  查看监视窗口或类似内容。

    [/引述]

    我想Julie给出了一个示例,其中监视窗口显示了错误的64位值(即变量存储在寄存器中而不是存储在内存中)。 这在我看来像是CCS中的一个错误(而不是编译器中的错误)。

    Markus

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

    George,

    如果您查看我提供的屏幕捕获,当观察窗口从2个寄存器排列64位数据时,显示的数据顺序错误。  应该是监视窗口显示中的问题。

    Julie

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

    如果您查看我提供的屏幕截图,当观察窗口从2个寄存器排列64位数据时,显示的数据顺序错误。  应该是监视窗口显示中的问题。

    我尝试在使用CCS 6.1 .2.0.0014万 和TI ARM编译器5.2 v.0 (与我安装的版本最近的版本)的AM1808中使用ARM9内核重复出现该问题。 我不能重复这个问题,因为 寄存器对中保留的SUM 64位SUM变量在变量视图中显示正确:

    在上面的工作示例中,在变量视图中,64位变量SUM的寄存器对位置为“R8:32,R9:32”,而在出现故障的情况下,该位置被指定为“R0”,即单个32位寄存器。

    您是否可以发布一个示例项目来显示问题以及准确的CCS版本号? 不确定问题是不是:

    A)您正在使用的CCS版本中的错误。

    B)编译器生成的调试信息为64位scale product_64变量指定了错误的寄存器位置。

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

    您好,切斯特,

    我正在使用的CCS版本是6.1 .0.0.0104万。 该项目是针对UCD3138的,我已附上了屏幕截图以了解详细信息。

    Julie

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

    CCS版本是 版本:6.1 UCD3138 0.0.0104万 , 我已附上屏幕截图以获取详细信息。

    感谢您提供信息。 我没有安装该CCS版本,也没有UCD3138,因此无法重新创建问题进行调查。

    不确定它是否重要,但UCD3138是big-endian,而我未能重新创建问题的ARM设备是little-endian。 希望TI的人员可以使用UCD3138重复此问题。

    您是否可以尝试更新的CCS版本以查看问题是否已在更新的版本中得到解决?

    例如,找到 的表达式和变量窗口未显示针对  CCS 6.1 .0.0.0104万 报告的正确值,因此 引发了错误SDSCM5.1806万,并在CCS 6.1 中修复了该错误1

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

    很抱歉,我的计算机上没有安装任何比6.1 .0.0.0104万 更新的CCS;因此我没有在更高版本上尝试。

    此致,

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

    Julie,

    我能够使用 UCD3138培训实验室固件包的实验1创建一个小型测试用例 ,并可以验证7.1 的CC382.0 (Windows)和CC380 6.2 (Ubuntu 16.04 /64)是否工作正常。  

    我正在将UCD3138OL64EVM-031与Spectrum Digital XDS200 USB JTAG调试探头配合使用。  

    因此,我只想更新您的CCS副本,以便从该错误中获益。

    希望这能有所帮助,

    拉斐尔

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

    很好地知道它在以后的版本中已修复。 感谢您检查此信息。

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

    I was able to create a small test case using 7.1 1 of UCD3138 training labs firmware package (使用UCD3138培训实验室固件包创建一个小型测试用例),并且可以验证CC3810_0 (Windows)和CC3810(2003)(Ubuntu_lab/64)<xmt-block1>2003 6.2 两个16.04 都工作正常

    。Rafael,您的屏幕截图显示scale product_64变量位于内存中(堆栈上)。

     Julie报告的问题是,编译器优化器放置在一对32位变量中的64位变量显示不正确,而64位全局变量显示正确。

    您是否能够使用优化级别为一(或更高)的UCD3138示例重新检查CCS v 6.2 0或v 7.1 0是否正确显示寄存器对中保留的64位变量?

    这可能需要一些实验,但我发现在优化级别1编译的以下代码片段导致SUM 64位变量存储在寄存器对中,而64位scale _product变量已根据调试信息进行了优化:

    #include <stdint.h>
    #include <stdio.h>
    
    int main (void)
    {
    	UINT32_t x = 0x8a2290;
    	UINT32_t y = 0xa000;
    	uint64_t scale_product;
    	uint64_t sum;
    	UINT32_t迭代;
    
    	SUM = 0;
    
    	对于(迭代= 0;迭代< 5;迭代++)
    	{
    		scale_product =(uint64_t) x * y;
    		printf ("0x%x * 0x%x = 0x%llx\n",x,y,scale_product);
    		sum += scale_product;
    	}
    	
    	返回总和;
    } 

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

    Julie,Chester,

    好的方面:我尝试了几种方法,但无法找到编译器将64位结果放置在系统中的寄存器对中的方法。  

    在搜索可能存在的未解决错误时,我在下面的文件中找到了SDSCM0.8685万:

    C:5.2 /ti//ccsv7/tools/compiler/ti-CGT-arm_CCES.9/Open_defects.html

    即使在现代ARM编译器发行版上,这仍然是一个未解决的错误,调试小组也有可能实施此处建议的变通办法:任意将变量的两半指向Rn:Rn+1并将它们放在变量/表达式视图上。 如上所述,ARM7是一个大型的Endian平台,由于数据可能是按相反顺序存储的,因此变通办法可能会失败。  

    我在我们的错误系统中搜索调试器的任何修复程序,我可以找到的最接近的修复程序是SDSCM3.9488万和 SDSCM4.2523万 -都被标记并确认为已修复。 但是,测试案例是针对其他体系结构的。  

    此时,我需要一个完整的测试案例来尝试在此平台中完全再现此情况。 我无法确认这在我们最新的IDE中是否仍然出色。  

    此致,

    拉斐尔

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

    此时,我需要一个完整的测试用例,以尝试在此平台中完全重现此问题。

    我已附上一个在 LAUNCXL2-570LC43上运行的测试用例。 虽然报告了ARM Cortex-R5F而不是ARM7问题,但我使用 了TMS570LC4357,因为它是一个大端臂器件。

    e2e.ti.com/.../TMS570LC43_5F00_multiply.zip

    该程序在许多CCS和TI ARM编译器版本上进行了测试。

    1) CCS 7.1 .0.0.0016万 和编译器5.2 .v.5:

    在此组合中,64位变量SUM的位置报告为单个“Register R5”(注册R5),并且该值错误地显示为0x559A0万000056,0.0056万,而不是预期的“0x0万56559A0000”5.6559万”。0000。

    2) CCS 7.1 .0.0.0016万 和编译器16.9 .3.LTS:

    在64位变量的位置组合中,一对32位寄存器"R7:32,R5:32",该值正确显示为 "0x0万56559A0000"。5.6559万。</s>0000

    3) CCS 6.1 .3.0.0033万 和编译器5.2 .v.5:

    在此组合中,64位变量SUM的位置报告为单个“Register R5”(注册R5),并且该值错误地显示为0x559A0万000056,0.0056万,而不是预期的“0x0万56559A0000”5.6559万”。0000。

    4) CCS 6.1 .3.0.0033万 和编译器16.9 .3.LTS:

    在这种组合中,CCS调试器报告一个错误,64位变量的寄存器未知。

    结论是:

    a) CCS 7.1 .0.0.0016万 (以及 CCS 6.1 .3.0.0033万)在寄存器对中错误地显示64位变量的值,导致上下32位字被交换, 当与TI ARM编译器一起使用时,该编译器仅将64位变量描述为32位寄存器中的变量,而ARM器件是BIG-Endian。

    b)在TI ARM编译器5.2 v.5和v.16.9 .3.LTS之间的某处,已对将64位变量描述为寄存器对的位置进行了更改,使CCS调试器能够正确显示ARM BIG-ENdiian器件上寄存器对中保留的64位变量。 但是,较旧的CCS版本无法理解新的调试信息。 不知道在6.1 3和7.1 之间的哪个CCS版本中更改了用于理解调试信息的更改。

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

    感谢您发送测试案例。 我发现7.1 4.0 + CGT 15.12 .5显示了该问题,而正如您所看到的,16.9 .3没有显示。

    我还看到6.2 4.0的行为与6.1 相似。3.

    由于找不到已解决的特定错误案例,我正在与其他一些来源核实可能发生了什么情况。

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

    我发现7.1 3.0 + CGT 15.12 5显示了该问题,而正如您所看到的,16.9 3没有显示。 [/QUOT]我查看了编译器为寄存器中保留的64位SUM变量生成的调试信息。

     使用v.16.9 .1.LTS时,会在以下位置报告注册对:

    ;* V2分配总计
    $C$DW7美元	.dwtag DW_tag_variable
    	.dwattr$C$DW7美元, DW_AT_name("sum")
    	.dwattr$C$DW7美元, DW_AT_TI_SYMBOL_NAME("sum")
    	.dwattr$C$DW7美元, DW_7美元_DW_$OP_Dw_$7$</s>7美元
    	

     使用v 15.12 .5.LTS时,只有一个寄存器作为位置报告:

    ;* V2分配总计
    $C$DW8美元	.dwtag DW_tag_variable
    	.dwattr$C$DW8美元, DW_AT_name("sum")
    	.dwattr$C$DW8美元,DW_AT_TI_SYMBOL_name("sum")
    	.dwattr$C$DW8美元, Dw_Dw_71美元$位置Dw_Dw_71美元$$
    	

    其中SUM类型是通过$C$DW$T71美元类型的64位:

    $C$DW$T71美元	.dwtag DW$T71美元
    	
    	,DW$DW$T71美元,DW_AT_NAME ("uint64_t").dwattr $C$DW$T71美元,DW_AT_TYPE (*$C$DW$T15美元).dwattr/Dw_D7.$
    	
    	语言编译器7美元$ 15.12
    	DW_AT_decl_line (0x33)
    	.dwattr $C$DW$T71美元,DW_AT_decl_column (0x20) 

    因此,v 15.12 .x和16.9 v.x系列编译器之间对调试信息进行了增强,允许寄存器中的64位变量被指定寄存器对的位置。