长双倍乘法是错误的

你看了XC16关于长双打的支持手册。除非你改变了编译器选项，否则HuntLouple双打可能不会被支持并且双打默认为单打。第一个代码看起来像编译器测试代码。优化器可以使它看起来像是被破坏了。将优化器设置为0零，或将变量声明为测试的易失性。



      以下为原文

    You read the XC16 Manual about support for Long doubles.  And Doubles for that matter.
Hint Long doubles may not be supported and doubles default to singles unless you change the compiler options.
 
The first code looks like compiler test code.  The Optimizer may make it look like it is broken. set the optimizer to 0 zero OR declare the variables as volatile for the Test.

不管数据类型是双还是浮动，结果对我来说都是一样的。如果我把它们乘以变量，答案就大错特错了，如果我把它们乘以文字，答案是正确的。加法、减法和除法都很好，只是乘法是不正确的。



      以下为原文

    It doesn't matter if the data type is double or float the result is the same for me. If I multiply them as variables the answer is grossly wrong and if I multiply them as literals the answer is correct. Addition, subtraction and division are fine, it's just multiplication is incorrect.

如果你不能费心阅读手册，那是你的错。



      以下为原文

    If you can't be bothered reading the manual, it's your fault.

嗨，PROFALL的第一百位16位PIC控制器的浮标和双浮标多年没有错误……所以不要指望简单的复制不起作用……正如上面一篇文章中提到的，XC16编译器文档提到默认情况下双处理为浮标。如果你计算程序中没有使用的变量，编译器也可以优化代码。



      以下为原文

    Hi,
 
Probalby 100th of thousand 16bits PIC controllers mutiply floats and double floats with no errors for years...
so do not expect that a simple mutliplication does not work...
As mentioned in a previous post above, the XC16 compiler documentation mentions that double are treated as floats by default (this can be changed).
Also compilers may optimize code away if you compute a variable which is not used in your program.
 
Regards

你正在用XC16编译器对错误行为做出非凡的声明。要认真对待，你需要发布清楚地显示XC16编译器做错误行为的结果的代码。



      以下为原文

   
You are making an extraordinary claim of faulty behavior with the XC16 compiler.
 
To be taken seriously you will need to post code that clearly shows the results of the XC16 compiler doing the faulty behavior.

我指出了长双倍，因为你贴了它。你使用它的事实表明，你是一个新的嵌入式编程在一个小CPU，并开始在一个64位的桌面与一个FPU。你怎么看的价值观？MPlabX？这有它自己的错误。包括模拟器吗？什么版本？首先要注意优化问题。将该值设置为全局的静态变量，并查看它是否持有正确答案。“测试”编译器的问题是允许删除“不执行代码”。测试代码往往什么也不做。



      以下为原文

    I pointed out the long double because you Posted it. the fact that you used it says you are new to embedded programming in a small CPU and started on a 64bit desktop with an FPU.
 
How are you looking at the values?  MPlabX? that has its own bugs.  Including simulator ones?  What version?
Take care of the Optimization first.  Set the value to a static volitile variable that is global and see if it hold the correct answer.  The issue with "testing" the compiler is it is allowed to delete do nothing code.  and test code tends to do nothing.

我可以在MPLAB V892模拟器中使用XC16V1.33复制OP的结果，代码如下：根据XC16用户指南，长双支持为64位浮点类型。



      以下为原文

    I am able to reproduce OP's results using XC16 v1.33 in MPLAB v8.92 Simulator with the following code:
#include
volatile long double tempa=0, tempb=0, tempc=0, tempd=0;
int main(void)
{
  tempa = 0.833333333333333;
  tempb = 25000.0;
  tempc = tempa * tempb; // 8898.66567325592
  tempd = 0.833333333333333 * 25000.0; // 20833.3320312500
  while (1);
}

According to the XC16 User's Guide, long double is supported as a 64-bit floating point type.

添加后缀L的结果如下：编辑：更新到最新的XC16V1.34，仍然得到相同的结果。：（



      以下为原文

    Adding the suffix L results in this:
#include
volatile long double tempa=0, tempb=0, tempc=0, tempd=0;
int main(void)
{
  tempa = 0.833333333333333L;
  tempb = 25000.0L;
  tempc = tempa * tempb; // 8898.66666666665
  tempd = 0.833333333333333L * 25000.0L; // 20833.3333333333
  while (1);
}

Edit: Updated to the latest XC16 v1.34 and still got the same results. :(

当你对文字进行数学运算时，结果将在程序编译期间计算，因此不会受到运行时数学库中的任何实现问题的影响。



      以下为原文

    When you perform math on literals, the result will be computed during program compilation and will thus not be affected by any implementation issues in the runtime math library.

这个例子正确地运行在一个实际的目标（PIC24FJ256GB210）上，使用XC16 1.24和32位和64位双。



      以下为原文

    #include  
 
volatile long double tempa=0, tempb=0, tempc=0, tempd=0;
int main(void)
{
  tempa = 0.833333333333333L;
  tempb = 25000.0L;
  tempc = tempa * tempb; // 8898.66666666665
  tempd = 0.833333333333333L * 25000.0L; // 20833.3333333333
  while (1);
}
 
This example runs correctly on an actual target (PIC24FJ256GB210) using XC16 1.24 with both 32 and 64 bit double.

嗨，同样正确的结果在模拟器像GOEK使用XC16V1.34（最新版本）和相同的源代码作为GoeKaCube



      以下为原文

    Hi,
Also correct results in simulator like GoEk using XC16 v1.34 (latest version) and same source code as GoEk
Regards

我的记录是1.24。



      以下为原文

   
For the record I am on 1.24.
 

在记录中，对DSPIC33 EP32 MC202的结果进行了模拟。在V1.24和V1.34的情况下，对PIC24FJ256GB210进行了模拟，得到了20833.3333333333的正确结果。



      以下为原文

   
For the record the results I got in Posts #8 and #9 were simulated for the dsPIC33EP32MC202. Same results with v1.24.
 
When simulating for the PIC24FJ256GB210 the correct result of 20833.3333333333 is observed with both v1.24 and v1.34.

随机改变PIC器件进行仿真，发现PIC24EP和DSPIC33 EP给出了错误的结果，而其他16位PIC器件（如其他PIC24、DSIC30、DSSPIC33 FJ）给出了正确的结果。



      以下为原文

    Changing PIC devices randomly for simulation, I've found that PIC24EP and dsPIC33EP give the wrong results,
while other 16-bit PIC devices (such as other PIC24, dsPIC30, dsPIC33FJ) give the correct results.

现在（太晚了）我看到OP KalMz没有指定任何测试条件。没有编译器，没有编译器版本，没有PIC，没有真正的代码，没有优化级别，没有信息他如何确定错误的值（8898.66567325592）。没有这些信息，我们再次猜测。我还测试了DSPIC33 EP32 MC202与模拟[编辑：但我正在使用MPLABX模拟器]，XC16V1.34使用OpTiim化水平0或1。尝试了双重和长期双重设置。我使用了来自8和9的代码，我无法验证上面的“错误”结果。我总是得到正确的结果（20833.33…），用“变量表”来验证。查看ANDLSM POST，我可以想象编译器优化了两个变量，并在编译时计算产品。但是我不能测试，因为我没有许可证（即我只能测试0和1）。在我的例子中，编译器调用MUDF3。下面的输出是由POST 9中的1和0的代码生成的，优化级别为0。



      以下为原文

    Now (too late) I see that OP kholmz did not specify any test condition. No compiler, no compiler version, no PIC, no real code, no optimization level, No information how he determines the wrong value (8898.66567325592).
Without that information we are again guessing.
 

I also tested dsPIC33EP32MC202 with simulation [edit: but I'm using MpLabX simulator], XC16 v1.34  using Optimization Level 0 or 1.  Tried with double and long double setting. I used the code from #8 and #9 and I cannot verify the above "wrong" result. I always get correct result (20833.33 ...), verified with "variable watch".
 
Looking at andersm post, I could imagine that the compiler optimizes the two variables away and calculates the product at compile time.  But I cannot test, because I don't have a license (i.e. I can only test 0 and 1).
In my case the compiler calls muldf3
 
The following output is generated by 1and0's code from post #9, optimization level 0
 
000004e2 <_main>:
volatile long double tempa=0, tempb=0, tempc=0, tempd=0;

int main(void)
{
 4e2:    00 00 fa        lnk       #0x0
 4e4:    88 9f be        mov.d     w8, [w15++]
 4e6:    8a 9f be        mov.d     w10, [w15++]
  tempa = 0.833333333333333L;
 4e8:    04 00 21        mov.w     #0x1000, w4
 4ea:    80 aa 2a        mov.w     #0xaaa8, w0
 4ec:    a1 aa 2a        mov.w     #0xaaaa, w1
 4ee:    a2 aa 2a        mov.w     #0xaaaa, w2
 4f0:    a3 fe 23        mov.w     #0x3fea, w3
 4f2:    00 9a be        mov.d     w0, [w4++]
 4f4:    02 92 be        mov.d     w2, [w4--]
  tempb = 25000.0L;
 4f6:    84 00 21        mov.w     #0x1008, w4
 4f8:    60 00 b8        mul.uu    w0, #0x0, w0
 4fa:    02 a0 26        mov.w     #0x6a00, w2
 4fc:    83 0d 24        mov.w     #0x40d8, w3
 4fe:    00 9a be        mov.d     w0, [w4++]
 500:    02 92 be        mov.d     w2, [w4--]
  tempc = tempa * tempb; // does NOT result in "wrong" 8898.66666666665, but instead in correct value.
 502:    00 00 21        mov.w     #0x1000, w0
 504:    10 04 78        mov.w     [w0], w8
 506:    90 04 90        mov.w     [w0+2], w9
 508:    20 05 90        mov.w     [w0+4], w10
 50a:    b0 05 90        mov.w     [w0+6], w11
 50c:    80 00 21        mov.w     #0x1008, w0
 50e:    90 00 90        mov.w     [w0+2], w1
 510:    20 01 90        mov.w     [w0+4], w2
 512:    b0 01 90        mov.w     [w0+6], w3
 514:    10 00 78        mov.w     [w0], w0
 516:    02 03 be        mov.d     w2, w6
 518:    00 02 be        mov.d     w0, w4
 51a:    08 00 be        mov.d     w8, w0
 51c:    0a 01 be        mov.d     w10, w2
 51e:    f0 fe 07        rcall     0x300 <___muldf3>
 520:    04 01 21        mov.w     #0x1010, w4
 522:    00 9a be        mov.d     w0, [w4++]
 524:    02 92 be        mov.d     w2, [w4--]
  tempd = 0.833333333333333L * 25000.0L; // 20833.3333333333
 526:    84 01 21        mov.w     #0x1018, w4
 528:    30 55 25        mov.w     #0x5553, w0
 52a:    51 55 25        mov.w     #0x5555, w1
 52c:    52 85 25        mov.w     #0x5855, w2
 52e:    43 0d 24        mov.w     #0x40d4, w3
 530:    00 9a be        mov.d     w0, [w4++]
 532:    02 92 be        mov.d     w2, [w4--]

00000534 <.L2>:
  while (1);
 534:    ff ff 37        bra       .
 
for further checks
http://www.binaryconvert.com/

我刚刚用MPLABX V4.15模拟器，XC16V1.34测试了相同的PIC设备，在手表窗口中得到了正确的结果。所以我猜这个bug是用MPLAB8模拟器做的。；）



      以下为原文

   
I just tested the same PIC device using MPLABX v4.15 simulator, XC16 v1.34, and got the correct results in the Watches window. So I guess the bug is with the MPLAB8 simulator. ;)
 

我在MPLAB V892上使用编译器XC16V1.25。使用带有目标DSPIC33 EP512GM310的模拟器。就像我说的，如果我把变量声明为浮点，它也会做同样的事情。感谢确认1＆0！



      以下为原文

    I'm using compiler XC16 v1.25 on MPLAB v8.92. Using the simulator with target dsPIC33EP512GM310. Like I said, evening if I declare the variable as a float it does the same thing. Thanks for confirmation 1and0!

因此，从我可以收集到的情况来看，您使用的是一个过时的IDE编译器，它在XC编译器发布之前还没有更新过，现在在IDE中的调试工具如何解码一个64位浮点格式方面存在问题。模拟器，在MPLABX，保持IDE，作为版本8.92的MPLAB还没有被更新了好几年。



      以下为原文

   
So, from what I can gather you are using a down-rev compiler with an obsolete IDE that has not been updated since before the XC compilers were released and now have a problem with how the debug tool in the IDE decodes a 64-bit floating point format.
 
You should consider perhaps using the debugger and simulator in MPLABX, the maintained IDE, as version 8.92 of MPLAB has not been updated in several years.

让我吃惊的是，这个bug只影响了PIC24E和DSPIC33，但影响了其他16位PIC设备。我本以为它要么工作要么不工作。哦，好吧。



      以下为原文

   
What surprised me is this bug affected only the PIC24E and dsPIC33E but _not_ the other 16-bit PIC devices.  I'd had expected it to either work or not work at all. Oh well.