6502 KIMATH, should I try and port it to Z80 or AVR mega? - Page 1
Forum section: electronics / general

author: commie
author_rank: Frequent Contributor
timestamp: October 17, 2015, 09:36:15 pm
content: Hi folks,I'm having a tough time here trying to figure out my best next move forward. I want decimal floating point capability and I've got an old package by mos technology from about 1977 which basically consists of a bunch of 6502 routines that you can string together and produce a potential 16 decimal(bcd) digits of mantissa(that's very powerful). If I build a 6502 system, then you are looking at about 10~15 chips, I have no compiler support for the 6502, other than an assembler. The total code consists of about 750 instructions and fits inside a 2krom.I've got compiler support for the 8051, AVR and the Z80. I want this package in a single chip AVR/8051 real bad, do you think it's viable to try and translate the 6502 assembler to AVR assembler, literally coded instruction for instruction? Failing that, I could try and port it to Z80 assembler.So anyhow, what do you think I should do?Problem with the AVR is that it is Harvard and so ram and rom space is split, this isn't the case with the Z80.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: October 17, 2015, 09:54:27 pm
content: http://www.micromegacorp.com/make this add on fpu for avrs and things. its interesting, uses i2c/spi to talk etc. 5v tolerant. may or may not be useful info.

author: John_ITIC
author_rank: Frequent Contributor
timestamp: October 17, 2015, 10:07:50 pm
content: Quote from: commie on October 17, 2015, 09:36:15 pmWhy is this a problem? Surely, the linker/locator puts the code in ROM and data in RAM automatically? Split address spaces is an advantage for 8-bitters since it effectively doubles the address space.

author: westfw
author_rank: Super Contributor
timestamp: October 17, 2015, 11:27:22 pm
content: IIRC, there is a 6502 emulator that runs on AVR...(Hmm. Several, it seems.http://sbc.rictor.org/avr65c02.html)

author: codeboy2k
author_rank: Super Contributor
timestamp: October 18, 2015, 12:15:02 am
content: I don't know what you're doing, but here's a free 6502 C compiler that's actively being worked on.codehttps://github.com/cc65/cc65wikihttps://github.com/cc65/wiki/wiki

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 18, 2015, 03:34:47 am
content: Quote from: commie on October 17, 2015, 09:36:15 pmMCS BASIC-52 (http://home.arcor.de/h.boehling/80c32.htm) includes an 8 digit BCD floating point package, which might be easier to extend than porting 6502 code.QuoteShouldn't be a problem unless the 6502 code is self-modifying.QuoteYes. You will have to take into account different side effects of the opcodes (what flags they set etc.) and how the program uses them, but a good macro assembler should be able to translate the actual instructions quite easily. Many years ago I wrote an 8051 assembler that used 6502 style mnemonics, because I hated the Intel ones!

author: westfw
author_rank: Super Contributor
timestamp: October 18, 2015, 05:38:48 am
content: I also don't see why a homebrew 6502 system should be "10-15 chips."http://www.philpem.me.uk/elec/6502/? "modernized" 6502 systems are all over the web (some taking pains to be backward compatible with original older designs...)

author: ale500
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:09:20 am
content: You may want to roll your own, specially if you can write it in C. You don't really need BCD if you use something like base 100 or 10000. Look for the unix command bc, the sources.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:23:21 am
content: Quote from: John_ITIC on October 17, 2015, 10:07:50 pmBecause in the AVR assembler (Studio 4) you have code/data segments assembler directives, this might not be a problem though.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:29:53 am
content: Quote from: wilfred on October 17, 2015, 11:21:52 pmI have tried looking for BCD floating point routines for other processors, I came close with the Z80, but unfortunately couldn't get it to work on my simulator.Out of all the processors available to me the 6502 is the only one which offers a 16 digit floating point package. Believe you me I have searched high and low for the AVR but nothing.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:42:29 am
content: Quote from: Bruce Abbott on October 18, 2015, 03:34:47 amI am aware of MCS BASIC-52, I also have Microsoft 6502 basic and Microsoft Z80 basics all sporting 9 digit resolution. , I'm foaming at the mouth for 16 digits.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:53:08 am
content: Quote from: westfw on October 18, 2015, 05:38:48 amHI Westfw,If I design a 6502 system, then I want to build it around the KIM 1 hardware, this will give me terminal and other support.

author: mikerj
author_rank: Super Contributor
timestamp: October 18, 2015, 10:54:06 am
content: Just use one of the numerous arbitrary precision math packages around. The GNU 'bc' library has been ported toArduinoso you are good to go with an AVR.

author: Kalvin
author_rank: Super Contributor
timestamp: October 18, 2015, 02:38:32 pm
content: Quote from: mikerj on October 18, 2015, 10:54:06 amAnd it looks that Nick Gammon has implemented a nice C++ wrapper, which allows using familiar algebraic notation without pain.

author: Ian.M
author_rank: Super Contributor
timestamp: October 18, 2015, 03:08:42 pm
content: I wouldn't build a 6502 system on a bet. At least a 8051 has current cross-assemblers and cross-compilers available, and a Z80 system can run CPM if you provide enough RAM, bulk storage (e.g. CF card) and a UART for a terminal.Porting a maths package without a deep knowledge of the original architecture and instruction set and preferable a working system with debugger or accurate emulator is going to be a royal PITA, and debuggong it will be even worse. If the source processor has a DAA instruction and the target processor doesn't or visa-versa, all BCD maths routines will need a total rewrite.However if you want a powerful home-build 'retro' SBC, why not use a Motorola 68008? You get most of the benefit of a 16 bit CPU with only an 8 bit bus, with no nasty multiplexing to deal with. You can cross-compile for it with GCC which means the word is your oyster for maths packages that will run on it. Take a look at:http://www.bigmessowires.com/2014/11/17/68-katy-68000-linux-on-a-solderless-breadboard/

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 03:48:43 pm
content: Quote from: westfw on October 18, 2015, 05:38:48 amHi Westfw,I must admit the chip count is a bit steep, however I was going to design it around the KIM 1 giving me microsoft basic and the well written KIM monitor (running 1MHz only) which might explain the high chip count.I have since decided to go another route giving me microsoft basic and 2 to 4MHz clk rate and at the same time halving the chip count.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 04:02:28 pm
content: Quote from: Ian.M on October 18, 2015, 03:08:42 pmYep, I was just mulling over the AVR instruction set a little while back, has no DAA and no SED set decimal mode instructions, that's looking nasty as you say.But I'm glad someone recognises how difficult the task is. I just want to point out something else as well, my AVR compiler supports IEEE 754 64-bit floats, but I can't use it because of the errors induced into the argument going from in to out and out to in and that's why calculators only use bcd.

author: zapta
author_rank: Super Contributor
timestamp: October 18, 2015, 04:34:11 pm
content: Choosing a 6502 architecture just because you found a 6502 decimal library seems too harsh. I would keep searching for a more portable C/C++ package.What kind of match operation do you want to have with decimal accuracy?Also, remember that you don't have to use bcd to achieve decimal accuracy. You can use binary with decimal exponent or if you want actual decimal representation you can pack two digits in one byte (range 0-99) to make the decimal carry/adjustment easier.A quick internet search brings these:http://speleotrove.com/decimal/decarith.html// specificationhttp://speleotrove.com/decimal/dnintro.html// one implementation in CGet a decent package and a modern, small, and cheap ARM MCU (they are cheap) and you will be set.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 18, 2015, 08:07:05 pm
content: Quote from: commie on October 18, 2015, 04:02:28 pmNo DAA? Well I guess you will just have to give up on the AVR.Or...

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 08:51:49 pm
content: Quote from: Ian.M on October 18, 2015, 03:08:42 pmQuick run through Mouser reveals no 68k for sale, in fact they have never heard or seen it before. However, the 6502 and Z80 with support chips are still available for sale. I don't think corporate America liked the 68k for some reason?

author: Macbeth
author_rank: Super Contributor
timestamp: October 18, 2015, 09:18:04 pm
content: I don't understand this thread. Surely whatever is coded into this 6502 routine is derived from an algorithm that you can easily translate to whatever CPU you choose?I do have a fondness for 6502 because when I was a kid I had a BBC Micro and having the best version of BBC BASIC on the planet that also had inline 6502 assembly (two pass, so labels too!) I would often drop into assembler. However as assembler goes it was definitely RISC (before that became a thing). Programming Z80 was much easier, well, except for the ZX Spectrum REM statements or my old SHARP MZ-80 that I actually hand coded in hex using the back of the reference manual (oh wow, I would actually calculate the JRNZ's by hand and type them in in hex - no mnemonics)Seriously, why are you fixated on a math function from the 70's in 6502 to port to AVR when there are so many others you could use instead?If it is just because you really want to then look at reverse engineering it (figuring out the higher level implementation) and then converting it if that floats ya boat!

author: Ian.M
author_rank: Super Contributor
timestamp: October 18, 2015, 09:36:46 pm
content: You'll need to pick one up NOS or refurb off ebay or similar e.g.http://www.ebay.ca/itm/1pcs-MC68008P8-MC68008-16-Bit-Microprocessor-With-8-Bit-Data-Bus-/261349278378If you don't need a DIP package, the PLCC version has two more bits of address bus giving a 4MB address range - which makes it possible to add more RAM for stuff like uClinux.

author: wd5gnr
author_rank: Regular Contributor
timestamp: October 18, 2015, 09:43:58 pm
content: Quote from: BloodyCactus on October 17, 2015, 09:54:27 pmAnd the venerable:http://www.awce.com/pak1.htm-- surprising what these have found their way in. If you prefer an "ASCII" calculator tryhttp://awce.com/pak12.htm

author: retrolefty
author_rank: Super Contributor
timestamp: October 18, 2015, 09:46:47 pm
content: Quote from: commie on October 18, 2015, 08:51:49 pmHoneywell used 68K chips for a couple of decades with their TDC-3000 (and follow-up models) DCS process control systems. 68040 was the last chip I saw being used by them when I retired.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 09:52:16 pm
content: Quote from: Bruce Abbott on October 18, 2015, 08:07:05 pmWell, I learned something today, hence the AVR has no BCD support instructions in it, I just can't believe it..Anyway thanks for posting those AVR routines, note I'm not trying to convert from binary to bcd or bcd to binary, instead I want to do bcd arithmetic.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:02:06 pm
content: Quote from: wd5gnr on October 18, 2015, 09:43:58 pmHere we go again, you cannot use 32 or 64 bit IEEE 754 floating point for accurate calculations, the reason for this is that there is a error prone conversion process going from ascii to fp and from fp back to ascii. The solution to this problem is to use BCD notation which requires no error going in/out of the processor.

author: commie
author_rank: Frequent Contributor
timestamp: October 18, 2015, 10:12:39 pm
content: Quote from: Macbeth on October 18, 2015, 09:18:04 pmYou must be joking, you think software comes equipped with a flow chart?Quote from: Macbeth on October 18, 2015, 09:18:04 pmBecause up to the present, there is nothing to replace it.Why did TI use an old '70's z80 for their range of graphing calculators?

author: IanB
author_rank: Super Contributor
timestamp: October 18, 2015, 10:50:29 pm
content: Quote from: commie on October 18, 2015, 04:02:28 pmQuote from: commie on October 18, 2015, 10:02:06 pmThis is not, in fact, true. You are creating difficulties for yourself by imagining a problem that is not there.When used correctly, floating point arithmetic in any base is just as susceptible to precision errors as in any other base (whether decimal or binary). Where BCD is chosen (for example for financial calculations) it is fixed point, not floating point. Fixed point leads to a different set of issues, which in same applications may be easier to manage.There is a reason scientific computing is done with binary floating point arithmetic on every computer in the world. Pocket calculators were designed differently not for reasons of precision or accuracy, but for convenience of design with a small chip count and low power consumption. Double precision 64-bit IEEE 754 is far more accurate than any pocket calculator I have compared it with.

author: Macbeth
author_rank: Super Contributor
timestamp: October 18, 2015, 10:55:51 pm
content: commie, no flow chart - you just need to use something called a disassembler. Make your own from that.Besides the only time I've ever encountered such (non floating) decimal point is in crappy ancient mainframe COBOL stuff that was riddled with Y2K bugs.The principle is very simple - why not code your own from scratch?

author: Ian.M
author_rank: Super Contributor
timestamp: October 18, 2015, 11:14:43 pm
content: Writing high precision floating point applications for a legacy 8 bit CPU in assembler is pure masochism. You either have or can obtain C compilers for all your potential targets except the 6502, and already have been pointed at an ANSI C IEE 754 decimal64/decimal128 compatible float library.

author: richardman
author_rank: Frequent Contributor
timestamp: October 18, 2015, 11:35:37 pm
content: I am sure a 84MHz STM32F411 at $7 a chip, will run a 6502 emulator faster than a 1MHz 6502 :-), let alone with all the other alternative ways that people have suggested already.

author: westfw
author_rank: Super Contributor
timestamp: October 19, 2015, 01:56:48 am
content: Quotethey were one of the first things to disappear in "RISC" instruction sets.QuoteAs Ian said, this is crap. There is a deterministic and predictable imprecision in conversion of ascii decimal floating point numbers to binary representations. If your program is constantly converting back and forth, it might need to pay attention to this. (but, most programs don't.) (and... any floating point representation introduces errors that you need to pay attention to in high-precision calculations, just because there are always some values that can't be represented exactly. They used to teach this, back when floats were only 32 to 36 bits. It seems largely ignored now that they're 64 to 80 bits or more.)Do you need actual floating point? As several people have pointed out, there are a bunch of standard multi-precision libraries written in nice level languages with lots of documentation. Some have been ported to small microcontrollers - for example the gnu "bc" library has been ported to Arduino:http://www.gammon.com.au/forum/?id=11519Several languages support arbitrary precision math in addition to standard floating point formats...

author: daybyter
author_rank: Frequent Contributor
timestamp: October 19, 2015, 03:24:59 am
content: http://www.stm32duino.com/viewtopic.php?f=19&t=433

author: ale500
author_rank: Frequent Contributor
timestamp: October 19, 2015, 05:02:56 am
content: QuoteThe reason: speed. No other reason. If decimal arithmetic were as fast as binary, binary would not be used. And anyways at least for chemistry, the constants used to describe the atoms are 7, 8, 9 digits accurate...

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 19, 2015, 05:22:40 pm
content: Quote from: commie on October 18, 2015, 09:52:16 pm;**** A P P L I C A T I O N N O T E A V R 2 0 4 ************************;*;* Title:BCD Arithmetics;* Version: 1.1;* Last updated: 97.07.04;* Target: AT90Sxxxx (All AVR Devices);*;* Support E-mail: avr@atmel.com;*;* DESCRIPTION;* This Application Note lists subroutines for the following Binary Coded;* Decimal arithmetic applications:;*;* Binary 16 to BCD Conversion (special considerations for AT90Sxx0x);* Binary 8 to BCD Conversion;* BCD to Binary 16 Conversion;* BCD to Binary 8 Conversion;* 2-Digit BCD Addition;* 2-Digit BCD Subtraction

author: commie
author_rank: Frequent Contributor
timestamp: October 19, 2015, 07:35:06 pm
content: Quote from: Bruce Abbott on October 19, 2015, 05:22:40 pmBruce, thank you for trying, I have seen this document and I can already do 2 digit bcd add/subtract. What I am looking for is 'at least' 16 digits bcd multiply and divide with auto exponents.

author: commie
author_rank: Frequent Contributor
timestamp: October 19, 2015, 07:58:23 pm
content: Quote from: westfw on October 19, 2015, 01:56:48 amWhy is it crap?, Using IEEE754 32 bit floats requires two associated i/o routines for use which convert an ascii string(number) into 32 bit floating point format, this input routine introduces small errors.Some numbers have an exact fit but many don't and those that don't fit produce a small error. If you now send the same 32 bit float to the screen there is likely to be yet another small error introduced because of the conversion process of the output routine.IEEE754 fp's are extremely byte efficient, at the expense of accuracy because IEEE754 require elaborate i/o routines to function correctly.BCD floating point, on the other hand, don't need an i/o routine, they are completely transparent to binary/hex and decimal. Do you think the smart guys would include bcd floating point arithmetic in our compilers? and if they did, risk destroying the international calculator industry at large?IEEE 754 is of course okay for use in the process/instrumentation industry because we only display the result to one or two fractional decimal digits where errors of IEEE754 don't show or are too small to be any significance.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 20, 2015, 08:19:57 am
content: Quote from: commie on October 19, 2015, 07:35:06 pmThe 6502 only two has instructions that use BCD - ADC and SBC. If you can emulate these on the AVR then porting the the rest of the code should be easy. AVR204 show you how to do it.

author: Kalvin
author_rank: Super Contributor
timestamp: October 20, 2015, 11:01:32 am
content: You can even use one byte for each digit, so you don't have to use the BCD-related instructions and you don't have to unpack and pack the digits when performing multiply and division, for instance. The exponent +/- 127 can be packed into one byte, it can be used as an ordinary signed integer, and it will not suffer from the rounding errors. One-byte-per-digit "wastes" some memory, but otherwise it will make your life easier. And, if the RAM space is really of concern, you can always unpack and pack the numbers before and after you operate on the numbers.

author: westfw
author_rank: Super Contributor
timestamp: October 20, 2015, 03:28:19 pm
content: Ooohh. There is now "Dense Packed Decimal." 3 digits in 10bits. (though apparently you unpack it to use it...)

author: Kalvin
author_rank: Super Contributor
timestamp: October 20, 2015, 03:37:59 pm
content: Quote from: westfw on October 20, 2015, 03:28:19 pmBetter yet, you can pack four digits in the 14bits!

author: commie
author_rank: Frequent Contributor
timestamp: October 20, 2015, 06:50:21 pm
content: Quote from: Kalvin on October 20, 2015, 11:01:32 amThe KImath routines use packed and unpacked bcd extensively, their argument for doing this, is it makes bcd multiplication/division execution very quick and one website I have came across, goes so far as to say unpacked bcd is the only way to bcd multiplication/division.KImath was introduced for the Mos Technology 6502 KIM 1 sometime during 1976. I have two books, one for the 6502 the other for the Z80, these books were published during 1984, in both of them I have found a multi digit bcd multiplication/division/subtraction and addition routines.I've keyed in the multiplication routine and sure enough it works, to increase the number of digits is trivial. Nowhere in the text is there any hint or reference to packed/unpacked bcd?. The routine is about 200 bytes long and is complicated, I get lost trying to follow it but there you go.The problem now is, how do I attach an exponent to a multi byte bcd number? The only viable way I can think of, is repeated division by 10 and counting the divisions until the number drops below 10 in value, the division count is then your exponent value.If anyones interested, "Z80 ASSEMBLY LANGUAGE SUBROUTINES", by Lance A. Leventhal and Winthrop Saville 1983

author: westfw
author_rank: Super Contributor
timestamp: October 21, 2015, 09:30:18 am
content: You still haven't said what's wrong with the existing multi-precision libraries. The BC library that's been ported to Arduino is one digit per byte, so it shouldn't have any problem addressing your concerns about conversion accuracy...

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 21, 2015, 05:45:23 pm
content: Quote from: commie on October 20, 2015, 06:50:21 pmDo you mean how to convert a BCD integer or fixed point number (eg. 12345.6789) to floating point (eg. 1.23456789 e+4)? Just skip any leading zeros and count the number of digits before/after the decimal point.

author: commie
author_rank: Frequent Contributor
timestamp: October 21, 2015, 06:24:53 pm
content: Quote from: Bruce Abbott on October 21, 2015, 05:45:23 pmHi Bruce,Yep, that's what I thought originally, but supposing you multiply two 12 digit fixed point numbers together and suppose the answer comes out with say arbitrary as 1234000056789, i.e., note the zero's are embedded in the result, so my zero detector comes along and detects a pair of zeros and my software thinks it has come to the end of the result when in fact it all it has done is detected zero in the middle of the result, right?

author: ale500
author_rank: Frequent Contributor
timestamp: October 21, 2015, 06:38:04 pm
content: You don't stop at zeros.. you have to count them all. Because each digit on the right of the first non-zero on the left if not significant because of limited number of digits give you the exponent when on the left of the decimal point.I follow this from the start and I think you may be seeing this thing all wrong. Just write on paper how the number should look like and how you are going to store it. You may get a better picture. Your "floating point" number is a structure with three fields, the exponent is one of them, you store it either at the beginning or at the end it doesn't matter as long as you always treat the structure the same way...

author: commie
author_rank: Frequent Contributor
timestamp: October 21, 2015, 07:05:13 pm
content: Quote from: ale500 on October 21, 2015, 06:38:04 pmYour last post has given me new inspiration, I was counting from the wrong direction/end, thanks for that Bruce and ALE500.I've got some work to do.

author: exmadscientist
author_rank: Frequent Contributor
timestamp: October 22, 2015, 04:37:33 am
content: Quote from: commie on October 18, 2015, 10:02:06 pmQuote from: commie on October 19, 2015, 07:58:23 pmBruce Dawson has what is, in my mind,the definitive response to this... concern....Hisentire series of blog posts on IEEE-754 floating pointis highly recommended reading for anyone who wants to really understand -- or thinks they already understand -- the guts and twisted dark corners of IEEE-754.

author: ale500
author_rank: Frequent Contributor
timestamp: October 22, 2015, 04:51:28 am
content: Here is some working code in C for BCD fp mul:I compiled it and tested in avr, arm and pic32 (mips). The given time is for mips. It encodes one BCD (base-10) per byte. I went for base 100 because you get the same speed for two times the number of digits.Code:#ifdef SMALL#define BCD_MAXDIGITS 8#define BCD_MAXWIDTH 13#define BCD_MAX_EXP 99#define BCD_MIN_EXP -99typedef int8_t exp_t;#else#define BCD_MAXDIGITS 20 // we should safely get 16 decimal places#define BCD_MAXWIDTH 24#define BCD_MAX_EXP 999#define BCD_MIN_EXP -999typedef int16_t exp_t;#endif#define BCD_LASTDIGIT (BCD_MAXDIGITS-1)typedef struct {uint8_t sign;exp_t dexp;uint8_t frac;} T_SBCDREAL;_CNT uint8_t mullow[] = { { 0 },{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 },{ 0, 2, 4, 6, 8, 0, 2, 4, 6, 8 },{ 0, 3, 6, 9, 2, 5, 8, 1, 4, 7 },{ 0, 4, 8, 2, 6, 0, 4, 8, 2, 6 },{ 0, 5, 0, 5, 0, 5, 0, 5, 0, 5 },{ 0, 6, 2, 8, 4, 0, 6, 2, 8, 4 },{ 0, 7, 4, 1, 8, 5, 2, 9, 6, 3 },{ 0, 8, 6, 4, 2, 0, 8, 6, 4, 2 },{ 0, 9, 8, 7, 6, 5, 4, 3, 2, 1 } };_CNT uint8_t mulhigh[] = { { 0 },{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },{ 0, 0, 0, 0, 0, 1, 1, 1, 1, 1 },{ 0, 0, 0, 0, 1, 1, 1, 2, 2, 2 },{ 0, 0, 0, 1, 1, 2, 2, 2, 3, 3 },{ 0, 0, 1, 1, 2, 2, 3, 3, 4, 4 },{ 0, 0, 1, 1, 2, 3, 3, 4, 4, 5 },{ 0, 0, 1, 2, 2, 3, 4, 4, 5, 6 },{ 0, 0, 1, 2, 3, 4, 4, 5, 6, 7 },{ 0, 0, 1, 2, 3, 4, 5, 6, 7, 8 } };/*** Multiplies 2 BCD numbers* it can use the same number as argument and result* 99.99999999*99.99999999 takes 1833*2 with -O3*/void t_bcd_mul(T_SBCDREAL *r, T_SBCDREAL *a, T_SBCDREAL *b){int8_t i, j, k, y, c;uint8_t frac[BCD_MAXDIGITS*2];uint8_t *xl, *xh;r->dexp = a->dexp + b->dexp;r->sign = a->sign ^ b->sign;for (i = 0; i < BCD_MAXDIGITS+BCD_MAXDIGITS; i++) frac = 0;for (i = BCD_MAXDIGITS-1; i >= 0; i--){j = b->frac;if (j) {xl = (uint8_t *)&mullow;xh = (uint8_t *)&mulhigh;k = BCD_MAXDIGITS + i;c = 0;for (j = BCD_MAXDIGITS-1; j >= 0; j--, k--) {y = *(xl+a->frac) + c + frac;c = *(xh+a->frac);if (y >= 10){c++;y -= 10;}frac = y;}frac = c; // last carry}}if (c) { // MSD is the carryfor (i = 0; i < BCD_MAXDIGITS; i++)r->frac = frac;r->dexp++;r->frac = c;}elsefor (i = 0; i < BCD_MAXDIGITS; i++)r->frac = frac[i+1];}

author: commie
author_rank: Frequent Contributor
timestamp: October 22, 2015, 12:29:48 pm
content: Hi ALE500,I did a similar thing with BASCOM AVR using base 10, however I lost interest in my code because it compiled down to a massive 1.5kbytes that's just for multiplying two 16 digit bcd(fixed point) numbers together.Although given AVR flavours come up to 256k bytes, that shouldn't be a problem.

author: ale500
author_rank: Frequent Contributor
timestamp: October 22, 2015, 03:10:48 pm
content: On MIPS32 a base-100 version with similar code compiles to 312 bytes, not bad.