• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 1062 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Floating-point arithmetic on fixed-point processors?

Anonymous
Anonymous


Hi,

 

I would like to ask a question on floating-point numbers.

 

Floating-point numbers have sign, exponent and fraction bits, and their arithmetic is significantly more involving than fixed-point arithmetic. On processors without floating-point ALU, C standard libraries however still include functions like sin(), sinf(), sinl() , and they could all be executed successfully. Without floating-point ALU support, are all arithmetic steps (shifting, comparison, fraction and exponent arithmetic) done in software? I mean, being translated into primitive instructions and then executed on integer-type ALUs?

 

If true, I guess it would be significantly slower than on processors with floating-point ALU. Is there any quantitative measure, on C6000 and ARM processors for example, on the performance of floating-point arithmetic?

 

 

Zheng

 

 

 

  • 0
    TI__Guru**** 251180 points

    When the processor doesn't supply floating point instructions, those operations (add, multiply, etc.) are performed by calling functions in the RTS library.  Of course, these functions are some 20x-100x slower than using one instruction.  

    Thanks and regards,

    -George

  • Anonymous
    0 Anonymous in reply to George Mock

    George,

    I see it, thanks for explanation.

    Zheng

  • Anonymous
    0 Anonymous in reply to George Mock

    George,

     

    A perhaps silly question is that how could the RTS know if the processor has floating-point ALU?

     

    If the RTS is written for single processor, then this should be no problem because it (and RTS programmer) knows what environment it is on, so if there is floating-point ALU, then the programmer write codes using it; if not, he write software routine to simulate it. There need, and should, be only one version RTS.

     

    However, if the RTS is written to support a broad array of processors, assuming for example in the 80286 era, that some machine have floating-point processor and some not, then I guess the RTS writer might need to write at least two versions of the code: one utilizing floating-point ALU and one that doesn't.

     

    If there are different architectures, assuming for example, CRAY, SPRAC, Intel, then there might be many versions of the code.

     

    If there are more than one set of RTS, which one is selected at compiling time/run-time? I guess there might be several options:

    (1)  User (application programmer) select by himself

    (2)  RTS acquire it, either

    a.     Directly from a processor status/identification bit: "I have floating-point ALU, it is (where), please (how to) use it"

    b.    Indirectly query it from OS

     

    Is it the way that works? For example, if TI someday develops a C8000 series, in which some have floating-point ALU, some not, and TI also develops an RTS package to the whole C8000 series, would them be designed similar to the way described above?

     

    And I head that there are also some standard libraries like BOOST for scientific computation. If BOOST, or any similar library are intended to be running on different architectures, should they be designed in a similar way?

     

     

     

    Zheng

     

  • 0 in reply to Anonymous
    TI__Guru* 84285 points

    There are endless ways one could configure the library at run-time, but doing this at run-time would be too complicated and expensive for an embedded device.

    For TI compilers, you are expected to know at link time whether the target hardware has hardware floating point, and link in the correct library.  You can also specify libc.a and allow the compiler to choose for you based on the command-line options.

  • Anonymous
    0 Anonymous in reply to Archaeologist

    Archaeologist,

    I see it, thanks for the comment on embedded application.

    Zheng