Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
05/04/08 14:03
Modified:
  05/04/08 14:10

Read: times


 
#154372 - You\'re almost there
Responding to: ???'s previous message
Robert

Glad you got it 'almost' working. You are correct when you find that the number in the result is what you expect minus the decimal point. See, the decimal is accounted for in the EXP register which you copy directly to your result. The actual result is in Aarg0,1,2. The decimal position (if you may) is in Aexp. When you run the floating number through the Float2Int subroutine, it will do the conversion correctly. However, since an int cannot hold a fraction, you need to multiply the fractional integer by the number of decimal places you want to see.

Example : 11.658149 converted to int will yield just 11
If you want to see 11.65, you multiply the float by 100 and then call the float2int routine to get 1165. Now you put in the decimal between the 11 and 65 manually.

The routines were written a long while back as an exercise in studying how to manage floating point in assembly. I put this code in the public domain so others can benefit and learn too. As for users, there are people who have used this and acknowledged and there are those who havent. I will suggest you download the latest version from my website. I have a conversion tool too to help you generate FP numbers in Hex to put in your code. As for suitability or otherwise, the usual disclaimers apply.

I do not use floating point unless it is unavoidable. Why? Simply because the 8051 is not natively able to use FP. The moment you add floating point, you have added a bulk of code, and slowed down your program by quite a few orders of magnitude. My preferred practice is to use integer 16/32 bit and handle the fractions as shown above in the example.

Just to give you a hint. Doing an operation like you described in integer math will involve
1) 148000/12700 reduced to 1480/127 which can be easily handled in a single subroutine of a 16/16 divide
2) the same operation in FP will do this
148000 convert to FP notation
12700 convert to FP notation
FP division
Convert result to integer notation

What could be done in 1 operation is now 4 operations each of which will consume code space and execution time. Prefer - 1


I am sure there are other experts here who will dissuade you using FP if you can avoid it. Its not bad; you need to be aware of the points I made above before you use it.

Regards
Jerson

List of 9 messages in thread
TopicAuthorDate
Floating Point Routine Listed            01/01/70 00:00      
   Contact Jerson            01/01/70 00:00      
   Floating Point Routine Listed            01/01/70 00:00      
      Replied to personal email            01/01/70 00:00      
   Floating Point Routine Listed            01/01/70 00:00      
      You\'re almost there            01/01/70 00:00      
         Floating Point Routine Listed            01/01/70 00:00      
            No - I COUNTRY            01/01/70 00:00      
               Floating Point Routine Listed            01/01/70 00:00      

Back to Subject List