This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Soft floating point emulation problems


>> Even if the process dramatically reduced the number of floating points instructions, there are still a few ones...where they should not be (AFAIK)!!!
>> For example, in the library libm.a, there are 3 stf instructions.
>>
>> arm-linux/lib/libm.a
>>  290:   adad51ec        stfges  f5, [sp, #944]!
>>  308:   bd241146        stflts  f1, [r4, -#280]!
>>  470:   bd241146        stflts  f1, [r4, -#280]!
>>
>> I am quite confused !
>> I am wondering if I should have had generated gcc itsel with some kind of -msoft-float option (it was generated with -nfp in the configuration script).
>> Maybe is it a gcc configuration bug ?
>> Has anyone information about this problem ?
>> Does anyone know where could I find a set of floating-point instructions library ?
>>

>1) Are you sure these are really instructions in the code, and not
>constants in constant pools?  The latter is quite probable, and the
>disassembler can't tell this (find the object file containing this
>instructions, compile the file to assembly and look for the same
>instructions in the output file).

- Yes, there is code at this location.
...
 270:   ea0000ac        b       2b8 <__cbrt+0x2b8>
 274:   3fc29801        swicc   0x00c29801
 278:   e893366d        ldmia   r3, {r0, r2, r3, r5, r6, r9, sl, ip, sp}
 27c:   3fe91e2a        swicc   0x00e91e2a
 280:   6fe7e984        swivs   0x00e7e984
 284:   bffd5ae6        swilt   0x00fd5ae6
 288:   cfa20f0c        swigt   0x00a20f0c
 28c:   40039350        andmi   r9, r3, r0, asr r3
 290:   adad51ec        stfges  f5, [sp, #944]!
 294:   c000eb82        andgt   lr, r0, r2, lsl #23
 298:   77cd8d5d        undefined
 29c:   3ff8218d        swicc   0x00f8218d
 2a0:   de9028b4        mrcle   8, 4, r2, cr0, cr4, {5}
 2a4:   3fd6b69c        swicc   0x00d6b69c
 2a8:   ba168ff2        blt     5a4278 <__cbrt+0x5a4278>
        ...
 2b8:   e91babf0        ldmdb   fp, {r4, r5, r6, r7, r8, r9, fp, sp, pc}
....

>2) If they are real FP instructions, are they coming from asm statements
>in the source?

Actually, those instructions come from C code statements (return calling a)

  return __ldexp (x > 0.0 ? ym : -ym, xe / 3);
 220:   e28f2088        add     r2, pc, #136    ; 0x88
 224:   e892000c        ldmia   r2, {r2, r3}
 228:   e24bc030        sub     ip, fp, #48     ; 0x30
 22c:   e89c0003        ldmia   ip, {r0, r1}
 230:   ebfffffe        bl      0 <__cbrt>
 234:   e3500000        cmp     r0, #0  ; 0x0
 238:   e51b6028        ldr     r6, [fp, -#40]
 23c:   ca000093        bgt     254 <__cbrt+0x254>
 240:   e1a01005        mov     r1, r5
 244:   e1a00004        mov     r0, r4
 248:   ebfffffe        bl      0 <__cbrt>
 24c:   e1a05001        mov     r5, r1
 250:   e1a04000        mov     r4, r0
 254:   e1a00006        mov     r0, r6
 258:   e3a01003        mov     r1, #3  ; 0x3
 25c:   ebfffffe        bl      0 <__cbrt>
 260:   e1a02000        mov     r2, r0
 264:   e1a01005        mov     r1, r5
 268:   e1a00004        mov     r0, r4
 26c:   ebfffffe        bl      0 <__cbrt>
 270:   ea0000ac        b       2b8 <__cbrt+0x2b8>
 274:   3fc29801        swicc   0x00c29801
 278:   e893366d        ldmia   r3, {r0, r2, r3, r5, r6, r9, sl, ip, sp}
 27c:   3fe91e2a        swicc   0x00e91e2a
 280:   6fe7e984        swivs   0x00e7e984
 284:   bffd5ae6        swilt   0x00fd5ae6
 288:   cfa20f0c        swigt   0x00a20f0c
 28c:   40039350        andmi   r9, r3, r0, asr r3
 290:   adad51ec        stfges  f5, [sp, #944]!
 294:   c000eb82        andgt   lr, r0, r2, lsl #23
 298:   77cd8d5d        undefined
 29c:   3ff8218d        swicc   0x00f8218d
 2a0:   de9028b4        mrcle   8, 4, r2, cr0, cr4, {5}
 2a4:   3fd6b69c        swicc   0x00d6b69c
 2a8:   ba168ff2        blt     5a4278 <__cbrt+0x5a4278>
        ...

But the statement contains a call (ldexp) which might be a macro calling a macro calling a macro... that is maybe using assembler statement (???).
I'am still investigating...
Anyway, I don't think such statements should be allowed in a non floating point mode.

Regards,
Cyril Germond
E-mail : cyril.germond@philips.com



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]