8051 floating pt routines

I am looking for assembly language decimal floating pt arithmetic routines for the 8051 uC. They must aslo compute sqroot and logs. Willinng to purchase. E.Stepp snipped-for-privacy@mozaert.cas.uc.edu

Reply to
estepp1
Loading thread data ...

I am looking for 8051 assembly language decimal floating point arithmetic routines. I need to compute sqroot and logs also. Willing to purchase. E. Stepp snipped-for-privacy@mozart.cas.uc.edu

Reply to
estepp1

I am looking for 8051 assembly language decimal floating ptarithmetic routines. Need to compute sqroot and log as well. Willing to purchase. E. Stepp snipped-for-privacy@cinci.rr.com

Reply to
estepp1

I am trying to location 8051 assembly langauge decimal floating pt arithmetic routines. Need to compute sqroot and logs as well.Willing to purchase. snipped-for-privacy@mozart.cas.uc.edu

Reply to
estepp1

| I am trying to location 8051 assembly langauge decimal floating pt | arithmetic routines. Need to compute sqroot and logs as well.Willing | to purchase. | snipped-for-privacy@mozart.cas.uc.edu

You could try math51.zip off this website:

formatting link

--
MT

To reply directly, take all 5 occurrences of the letter 'y' out of my
 Click to see the full signature
Reply to
mark thomas

E. Stepp wrote

US Software had a product called '8051 FPAC', now sold to/by MicroDigital:

formatting link

Most C compilers come with a floating point library.

Point of warning: I have spent much time fixing client problems where the problem was traced to the math package. I would recommend getting a very mature and bug-free package if you are going to design it into a product.

The US Software package has been around for 20+ years and I do not know of any bugs in it, however, that doesn't mean the software hasn't been "improved" or isn't crawling with bugs I have never come accross.

Remember Intel's first Pentium that couldn't divide by 30,472 (or some such number). Tread carefully.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan

And many of them suck rather badly. ;)

I've use US Software's floating point libraries for 6811, and they were an order of magnitude faster than the ones that came with the C compiler. IIRC, there were some things that US did right (NaNs, infities) that the compiler library didn't handle correctly.

I also know people who used US Sotware's FP libs on 8051 and were happy with them.

--
Grant Edwards                   grante             Yow!  I'm also against
                                  at               BODY-SURFING!!
 Click to see the full signature
Reply to
Grant Edwards

I use Keil's f.p. libs and they seem ok - but *SLOOOOOOW*

Bob

Reply to
Bob Stephens

What about the INTEL FP library ? That's floating around on the web in various places. It was part of the Intel Basic52 processor.

Steve

Reply to
Steve Taylor

'e did axe for decimal. Any of these decimal? Not that it's a problem typically.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

I guess we all silently agree that he didn't really mean what he said, there. FP arithmetic on an 8051 is quite certainly slow enough already, without the extra burden of doing it in decimal.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I certainly assumed the OP didn't really mean decimal, and my comments were about IEEE binary FP. If the OP erally wants BCD FP for the 8051, I've no idea where to look.

--
Grant Edwards                   grante             Yow!  Yow! Did something
                                  at               bad happen or am I in a
 Click to see the full signature
Reply to
Grant Edwards

Same here: a stranger walks up and says "I just murdered your wife." Well I would think he is just having a bad med day. Wouldn't even cross my mind he was serious.

OK, now as to BCD floating point:

What is the reason for _needing_ decimal? And why _floating point_ decimal?

To my mind this is maybe a false requirement: there is no need for BCD floating point on an 8051 and therefore there is no readily available package.

US Software FPAC/GoFast is what you need.

"You can't always get what you want, You can't always get what you want, But you just may find, If you try sometime, you get what you need." Jagger

Rule of thumb: "If you can't find it then you don't need it." Conversely: "Everything you need is right at hand." Try it out for a day or two ... pretty amazing how well it works.

The US Software package will do ASCII float (I think). I never used this facility.

For interface to humans I convert float -> integer -> ASCII BCD for display. I scale the floating point value so it is between

-9999, 9999 convert to BCD/ASCII and stick the decimal point where I need it. There isn't much physical that needs more than

4 digits to describe it.

The only time I have found myself using BCD math as the native number base is on PIC projects, using a 16C54.

Cash registers and calculators use (or used) BCD as a native mode. Historically these were one-bit machines. The first uP (a 4 bit machine - 4004) was to go in an adding machine and so it had lots of BCD support.

Ergo cognito there must exist humungous libraries of BCD math functions. Slow, though, but so are calculator processors. There may be an advantage to BCD if _really_ long strings of numbers have to be dealt with:

2.3948820409852223123412349347e0047 * 9.3248751304512349817612341254e-004

Then the horrors of decimal -> binary -> decimal conversion might send me up a tree.

A 64 bit integer is equivalent to having 20 decimal digits, though, so I am sure the problem has been well solved.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan

The only situation I can think of this might be useful is in some financial calculations with strange rounding rules, especially in exchange rate conversions etc.

IIRC, before 2001 in the euro zone, the conversion from one national currency to an other had to go through the euro, with a euro representation of _exactly_ 5 decimal digits, which would have required either some BCD floating point or doing some intermediate step calculations on long binary integers, in which the actual unit would have meant a millicent :-). This would have required some multiplications and divisions of the _long_ integer by some powers of the ten. In a BCD floating implementation, these multiplications and divisions could simply be handled with exponent additions and subtractions.

So indeed a simple handheld exchange rate calculator might have used BCD floating point even on a much more simpler processor than the

8051.

Paul

Reply to
Paul Keinanen

A couple of possibilities-- the need to both do floating point and to represent decimal fractions exactly. Or wanting to avoid the overhead of conversion to/from decimal for display and/or communications.

Or, more likely, he doesn't know exactly what he wants. The request for log and sqrt may imply that.

It's not really any more difficult to write a math package to handle BCD than for binary on something like an 8051, but of course the expensive math operations such as divide and multiply tend to run slower (or require tables etc.).

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

"Paul Keinanen" wrote

I agree, accounting rules are the only compelling reason for using BCD. But the accounting specification could have just as easily specified 16 binary digits.

Besides, BCD is decimalist. If only we were born with 16 fingers ...

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan

... snip ...

Exactly. When I built my package for the 8080/z80 many moons ago I used a three byte format, with 8 bits for exponent, and 16 for significand with the implied leading 1 bit replaced by the sign. This give 4.7 decimal digits of accuracy, and all the arithmetic could be done in the registers. With care for proper rounding it outperformed the available four byte packages in both speed (by a factor of 5 to 10) and accuracy (over any extended calculations, such as a three by three matrix reduction). The system included i/o translation and formatting, and transcendental functions (trig, log, exp).

The accuracy was always more than enough for the physical things it was measuring and displaying.

For i/o I scaled to an integer in 6554..65535 and a power of ten, with a separate sign. Again 3 bytes, because the power of ten byte had room for a sign bit. The i/o worked with the resultant binary significands, and BCD never entered the picture.

A slightly less polished version was published in DDJ. It got faster and more compact later. IIRC it fitted into a single 2k eprom. Doesn't meet the C standard requirements though.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 Click to see the full signature
Reply to
CBFalconer

Yup. Financial calcualations are pretty much the only time BCD is used. For engineering and scientific stuff, it's binary FP.

--
Grant Edwards                   grante             Yow!  I like the way ONLY
                                  at               their mouths move... They
 Click to see the full signature
Reply to
Grant Edwards

I can't let this go without mentioning that just because 4 digits might be enough to describe something physical does NOT mean that you can get away with only 4 or 5 digits internally. I've run into a couple of situations over that years that made me glad I was paying rapt attention in university Numerical Methods class. ;-) Sometimes you can improve the algorithms to make them less sensitive, but it's not always possible, convenient or cost-effective.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

I understand that the IEEE is currently working on extending the floating point specification to also include decimal floating numbers. If I understood the proposal correctly, the internal (binary) representation would have been quite strange.

Paul

Reply to
Paul Keinanen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.