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 stepp@mozaert.cas.uc.edu
8051 floating pt routines
Started by ●February 22, 2005
Reply by ●February 23, 20052005-02-23
E. Stepp <estepp1@cinci.rr.com> wrote> 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.US Software had a product called '8051 FPAC', now sold to/by MicroDigital: http://www.smxinfo.com/index.html 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. To reply, remove spaces: n o lindan at ix . netcom . com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply by ●February 23, 20052005-02-23
On 2005-02-23, Nicholas O. Lindan <see@sig.com> wrote:> US Software had a product called '8051 FPAC', now sold to/by > MicroDigital: > > http://www.smxinfo.com/index.html > > Most C compilers come with a floating point library.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!! visi.com
Reply by ●February 23, 20052005-02-23
On 23 Feb 2005 16:32:03 GMT, Grant Edwards wrote:> On 2005-02-23, Nicholas O. Lindan <see@sig.com> wrote: > >> US Software had a product called '8051 FPAC', now sold to/by >> MicroDigital: >> >> http://www.smxinfo.com/index.html >> >> Most C compilers come with a floating point library. > > 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.I use Keil's f.p. libs and they seem ok - but *SLOOOOOOW* Bob
Reply by ●February 23, 20052005-02-23
Grant Edwards wrote:> On 2005-02-23, Nicholas O. Lindan <see@sig.com> wrote: > > >>US Software had a product called '8051 FPAC', now sold to/by >>MicroDigital: >> >> http://www.smxinfo.com/index.html >> >>Most C compilers come with a floating point library. > > > 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. >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 by ●February 23, 20052005-02-23
On Wed, 23 Feb 2005 16:51:37 GMT, the renowned Bob Stephens <stephensyomamadigital@earthlink.net> wrote:>On 23 Feb 2005 16:32:03 GMT, Grant Edwards wrote: > >> On 2005-02-23, Nicholas O. Lindan <see@sig.com> wrote: >> >>> US Software had a product called '8051 FPAC', now sold to/by >>> MicroDigital: >>> >>> http://www.smxinfo.com/index.html >>> >>> Most C compilers come with a floating point library. >> >> 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. > >I use Keil's f.p. libs and they seem ok - but *SLOOOOOOW* > > >Bob'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 Embedded software/hardware/analog Info for designers: http://www.speff.com
Reply by ●February 23, 20052005-02-23
Spehro Pefhany <speffSNIP@interlogdotyou.knowwhat> wrote:> 'e did axe for decimal. Any of these decimal?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 by ●February 23, 20052005-02-23
On 2005-02-23, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:> Spehro Pefhany <speffSNIP@interlogdotyou.knowwhat> wrote: > >> 'e did axe for decimal. Any of these decimal? > > 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.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 visi.com drive-in movie??
Reply by ●February 23, 20052005-02-23
"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote> Spehro Pefhany <speffSNIP@interlogdotyou.knowwhat> wrote:> > 'e did axe for decimal. Any of these decimal? > I guess we all silently agree that he didn't really mean what he said,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. To reply, remove spaces: n o lindan at ix . netcom . com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply by ●February 23, 20052005-02-23
On Wed, 23 Feb 2005 20:34:53 GMT, "Nicholas O. Lindan" <see@sig.com> wrote:>OK, now as to BCD floating point: > >What is the reason for _needing_ decimal? >And why _floating point_ decimal?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
