带mno-float的PIC32MZ EF浮点错误

您好，我使用PIC32 MZ2048 EFH064，XC32 V1.42，MPLAP X3.5.1，和声2.0.2.4，如果长浮点库关闭（MnO-FLUE），将下列两个“双浮点”分开，导致错误的结果。在调试会话中，使用PICIT3.3易失性长TestLDL；易失性长双TestLD2；易失性长双TestLD3；TestLD1＝100；TestLD2＝30；TestLL＝30；TestLD3＝100／30；//OK/*A*/TestLD3＝TestLD1/TestLD2；//OK/*B*/TestLD3＝TestLD1/TESTLL；//WRO；NG结果（无限或其他）/*C*/TestLD3= TestLD1//（long double）TESTLL；//错误结果（无限或其他）根据XC32编译器用户指南long long是一个64位支持的数据类型。如果我使用32位长类型的TestLL都很好。如果关掉浮点库（PIC的FPU），对32位数据类型有什么限制吗？我会假设使用标准的C数学库来代替？仅仅是数学，H或不改变任何东西。只是为了背景信息，我必须把FPU关掉，因为我也使用DSP内核，而且如果使用来自LIFBQYQ31的浮点将浮点DSP系数翻译成定点TPp，那么PIC32 MZ EF类型就有一个定时问题。ES由于从FPU到DSP内核的数据传输。在这个论坛上的另一个线程，我不在这里。作为一个规避，有可能应用源文件MNO-FLUP，还是总是对所有源文件？也许有人能给这种奇怪的行为带来更多的光亮？我做错什么了吗？谢谢米迦勒



      以下为原文

    Hi,

I am using PIC32MZ2048EFH064, XC32 V1.42, MPLAP X 3.5.1 with HARMony 2.0.2.4.
Doing the following divisions of 'double float' by 'long long' leads to wrong results if floating point library turned off (-mno -float).
The behaviour can be reproduced with the simulator, but leads also to wrong results in debug session with Pickit3.

volatile long long TestLL;
volatile long double TestLD1;
volatile long double TestLD2;
volatile long double TestLD3;           
        
                TestLD1 = 100;
                TestLD2 = 30;
                TestLL = 30;
            
                  TestLD3 = 100.0 / 30.0;                           //ok
        /*a*/  TestLD3 = TestLD1 / TestLD2;                   //ok
        /*b*/  TestLD3 = TestLD1 / TestLL;                     //wrong result (infinity or other)
        /*c*/   TestLD3 = TestLD1 / (long double) TestLL;  //wrong result (infinity or other)

According to the XC32 compiler user's guide long long is a 64 bit supported data type. If I use 32 bit long type for TestLL all is fine. Is there any limitation to 32 bit data types if the floating point library (FPU of PIC) is turned off? I would assume that standard C Math libraries are used instead? Including math.h or not does not change anything.

Just for background information, I have to turn the FPU off with -mno - float as I am using the DSP kernel as well and there is a timing issue with the PIC32MZ EF types if using _LIBQ_Q31FromFloat to translate float DSP coefficients to fixed point types because of data transfer from FPU to DSP Kernel. It is on another thread in this forum I don't have at hand here.

As a circumvention, is it possible to apply -mno-float by source file or is this always for all source files at once?

Maybe someone could bring a little bit more light into this strange behaviour? Am I doing something wrong?

Thanks Michael