Hi @airazusta,
So just adding more information about 32bit toolchain usage (which is compatible with Zynq-A9 cores) in case it might be useful for other forum users looking into floating point usages.
The 32bit toolchain supports the soft float ABIs and it can be configured through mfloat-abi option as documented in the GCC documentation. If you generate a 32bit target application on A53, you will see that mfloat-abi is set to hard both in the BSP settings and the application toolchain settings.
Taking a look to the ELF output generated with the same example used in the previous post you can see how FP instructions have been used (hard floating point).
a = 1.2;
550: e3032333 movw r2, #13107 ; 0x3333
554: e3432333 movt r2, #13107 ; 0x3333
558: e3033333 movw r3, #13107 ; 0x3333
55c: e3433ff3 movt r3, #16371 ; 0x3ff3
560: e14b20fc strd r2, [fp, #-12]
b = 2.4;
564: e3032333 movw r2, #13107 ; 0x3333
568: e3432333 movt r2, #13107 ; 0x3333
56c: e3033333 movw r3, #13107 ; 0x3333
570: e3443003 movt r3, #16387 ; 0x4003
574: e14b21f4 strd r2, [fp, #-20] ; 0xffffffec
c = a + b;
578: ed5b1b03 vldr d17, [fp, #-12]
57c: ed5b0b05 vldr d16, [fp, #-20] ; 0xffffffec
580: ee710ba0 vadd.f64 d16, d17, d16
584: ed4b0b07 vstr d16, [fp, #-28] ; 0xffffffe4
printf("Hello World %lf\n\r", c);
588: e14b21dc ldrd r2, [fp, #-28] ; 0xffffffe4
58c: e30c0e38 movw r0, #52792 ; 0xce38
590: e3400000 movt r0, #0
594: eb0000fd bl 990 <printf>Changing the mfloat-abi to soft will force the toolchain to use soft ABI for floating point operations rather than FP instruction, so the dissably code will look into something like:
a = 1.2;
550: e3032333 movw r2, #13107 ; 0x3333
554: e3432333 movt r2, #13107 ; 0x3333
558: e3033333 movw r3, #13107 ; 0x3333
55c: e3433ff3 movt r3, #16371 ; 0x3ff3
560: e14b20fc strd r2, [fp, #-12]
b = 2.4;
564: e3032333 movw r2, #13107 ; 0x3333
568: e3432333 movt r2, #13107 ; 0x3333
56c: e3033333 movw r3, #13107 ; 0x3333
570: e3443003 movt r3, #16387 ; 0x4003
574: e14b21f4 strd r2, [fp, #-20] ; 0xffffffec
c = a + b;
578: e14b00dc ldrd r0, [fp, #-12]
57c: e14b21d4 ldrd r2, [fp, #-20] ; 0xffffffec
580: eb000077 bl 764 <__adddf3>
584: e1a02000 mov r2, r0
588: e1a03001 mov r3, r1
58c: e14b21fc strd r2, [fp, #-28] ; 0xffffffe4
printf("Hello World %lf\n\r", c);Regards,
Ibai
Hi @ibaie,
Thank you for your answer, it was really helpful.
However, I've started trying the three possible compilation options (64 bit hard fp, 32 bit hard fp and 32 bit soft fp) with a very simple application and I got some incoherencies regarding the time they take for doing the FP operations. My application basically does the following: it calculates the time needed for making a FP adding operation.
int main()
{
XTime time_init, time_end, time_total;
float USecsElapsed;
float a,b,c;
XTime_GetTime(&time_init);
a = 1.2245;
b = 2.436898;
c = a + b;
XTime_GetTime(&time_end);
time_total = time_end - time_init;
USecsElapsed = ((float) (time_total * 1000000) / (float) COUNTS_PER_SECOND);
printf("Time required= %.3f us\r\n Cycles = %d\r\n", USecsElapsed, (int)time_total);
return 0;
}
I compiled the application in the three possible modes, I attach screenshots of the disassembly just to see it is done correctly:
- 64 bit architecture - Hard FP
- 32 bit architecture - Hard FP
- 32 bit architecture - Soft FP
And the times I obtained are the following ones:
- 64bit hard FP --> 0.94 us
- 32bit hard FP --> 0.32 us
- 32bit soft FP --> 0.7 us
I also tried multiplying 'a' and 'b' instead of adding them and I got these times:
- 64bit hard FP --> 0.94 us
- 32bit hard FP --> 0.32 us
- 32bit soft FP --> 0.56 us
Maybe I'm mistaken, but shouldn't be 64bit hard FP as fast as 32bit hard FP (or even faster) and not the slowest one?? In the three cases the time it takes XTime_GetTime() function for exectuing is the same (0.31us).
Best Regards,
Eskerrik asko :)
Ane
