PIC32MZ2048EFH064与xc32 1.43无法生成FPU指令

如果是从反汇编窗口中，那么忽略它。自从MPLABX的最后几个版本，它显示了至少PIC32 MZ设备的完全垃圾（我想自从采购经理出来之后）。例如，看看下面的**内嵌程序集*代码的解体。绝对（请原谅我的法语）B*LL@ $S在项目属性XC32（全局选项）中，选择“不要”。删除中间文件并重新构建。然后在ProjutNAM.x/Buud/CurrnTyCopy/Directory（其中ProjnNeXT和CurrutyOnFig是您的项目名称和当前选定的配置）下的某个地方，您将找到.s文件。



      以下为原文

    If that is from the disassembly window, then ignore it. Since the last few versions of MPLabX it shows complete rubbish for at least PIC32MZ devices (I think since the MM came out).
For example, look at the disassembly for the following *inline assembly* code.
!    asm volatile ("lui %0,0xbf86":"=r"(v0));                      //  Load v0 with hi word of address of Port SFR's
0x9D001718: LDC1 F0, -16506(V0)
!    //We now want to write the data in the cache out to PORTE
!    //So we need the KSEG0 address of data again
!    asm volatile ("addiu %0,$0,%%hi(%1)":"=r"(a0):"i"(data));
!    asm volatile ("andi %0,%0,0x8fff":"=r"(a0));
0x9D001720: BEQZ A3, 0x9D001720
!    asm volatile ("sll %0,%0,16":"=r"(a0));
0x9D001724: SLL S0, S0, 8
!    asm volatile ("ori %0,%%lo(%1)":"=r"(a0):"i"(data));
!    asm volatile ("addiu %0,%1,4096":"=r"(a1):"r"(a0));            //# Load a1 with a0+4096
0x9D00172C: ADDI A0, A1, 4096
!    asm volatile ("ori %0,$0,0x80":"=r"(t0));                      //  t0=0x80 (bit 7)
0x9D001730: SRA ZERO, T0, 0
!    asm volatile ("mtc0 $0,$25,1");  //clear stall counter
0x9D001734: SW ZERO, 4(SP)
Absolute (excuse my french) B*ll@$s.
 
In project properties, XC32 (Global Options), select 'Don't delete intermediate files' and re-build.
Then somewhere under the projectname.X/build/current_config/ directory (where projectname and current_config are your project name and current selected configurations) you will find the .s files.

嗯，那太令人失望了。在.s文件中，我找到了一个Mull s，但它仍然不像我预期的那样。虽然没有C代码是很难判断的，以帮助你弄清楚你在哪里。我会挖更深一点，看看我发现了什么，谢谢你的头。



      以下为原文

   
Well, that's disappointing.  In the .s file I did find a MUL.S, but it still doesn't look like I expected.  Although it is hard to tell without the .c code to help you figure out where you are. I will dig a little deeper and see what I find, thanks for the heads up though.

在Project属性-gt；构建中，添加以下内容“在生成后执行此行”（并检查Tigbox）。（道具）这将生成一个.cST文件，其中C代码和反汇编交织在PrimeNo.x目录中。如果您可以在这里发布结果（只需剪切并通过相关位），如果需要的话，我会仔细查看。



      以下为原文

    In project properties->Building, add the following to "Execute this line after build" (and check the tickbox).
${MP_CC_DIR}xc32-objdump -S ${ImageDir}${PROJECTNAME}.${IMAGE_TYPE}.elf > list.lst(props. to aschen0866 for that).
This will generate a .lst file with the C code and disassembly interleaved in the projectname.X directory.
 
If you can post the result here (just cut and past the relavent bits), I will look over it if you want.

好的，你会认为Microchip能做到这一点，并把它称为“DISSsC装配窗口”，所以我把它简化成几个这样的测试：程序看起来像这样，我猜这是正确的吗？它使用浮动寄存器和Mull指令。结果我花了半天的时间才得出这个结论。



      以下为原文

   


Well that's fancy, you would think Microchip could do that and call it something like "Dissassembly Window"
 
So I simplified it to just a couple of tests like this:
 int main ( void )
{
    
    volatile float f=3.333;
    volatile float j=88.383;
    volatile float result = f*j;
    
    volatile int i=303;
    volatile float intFloatResult = i*result;
    return ( 0);
}
 
And the assembly looks like this
 
int main ( void )
{
9d000834: 27bdffe0 addiu sp,sp,-32
9d000838: afbe001c sw s8,28(sp)
9d00083c: 03a0f021 move s8,sp
    
    volatile float f=3.333;
9d000840: 3c029d00 lui v0,0x9d00
9d000844: 8c4200ec lw v0,236(v0)
9d000848: afc20000 sw v0,0(s8)
    volatile float j=88.383;
9d00084c: 3c029d00 lui v0,0x9d00
9d000850: 8c4200f0 lw v0,240(v0)
9d000854: afc20004 sw v0,4(s8)
    volatile float result = f*j;
9d000858: 8fc30000 lw v1,0(s8)
9d00085c: 8fc20004 lw v0,4(s8)
9d000860: 44830000 mtc1 v1,$f0
9d000864: 44820800 mtc1 v0,$f1
9d000868: 46010002 mul.s $f0,$f0,$f1
9d00086c: 44020000 mfc1 v0,$f0
9d000870: afc20008 sw v0,8(s8)
    
    volatile int i=303;
9d000874: 2402012f li v0,303
9d000878: afc2000c sw v0,12(s8)
    volatile float intFloatResult = i*result;
9d00087c: 8fc2000c lw v0,12(s8)
9d000880: 44820000 mtc1 v0,$f0
9d000884: 46800020 cvt.s.w $f0,$f0
9d000888: 44030000 mfc1 v1,$f0
9d00088c: 8fc20008 lw v0,8(s8)
9d000890: 44830800 mtc1 v1,$f1
9d000894: 44820000 mtc1 v0,$f0
9d000898: 46000842 mul.s $f1,$f1,$f0
9d00089c: 44020800 mfc1 v0,$f1
9d0008a0: afc20010 sw v0,16(s8)
    return ( 0);
9d0008a4: 00001021 move v0,zero
}
9d0008a8: 03c0e821 move sp,s8
9d0008ac: 8fbe001c lw s8,28(sp)
9d0008b0: 27bd0020 addiu sp,sp,32
9d0008b4: 03e00008 jr ra
9d0008b8: 00000000 nop
 
I guess this is correct? It is using the float registers and the mul.s instruction. To bad it took me half a day to come to this conclusion.