64bit Fixed point math library for small mcus needed

[iMo]

I've been looking for a simple 64bit fixed point library for small mcus (like modern clone of 8051/2 with 2kB of xram and 62kB of flash).
Like add, sub, mul, div, sqrt with 8.56 or 16.48 or 32.32 one, where the C compiler supports only int32_t.
I found some but the requirement is the C compiler has to provide int64_t..

Edit: specified the mcu

[voltsandjolts]

avr-gcc for AVR 8-bit provides int64_t

[iMo]

I need it for 8051/52, my C supports 32bit integers only..

[voltsandjolts]

OK, so when you said "for small mcus (like 8051 with 1kB xram)" what you meant was "for 8051".
Have fun with that.

[iMo]

It runs 32bit floating point, the 64bit int or floating point is not available, and the decNumber does not fit in.. 
Fixed above the mcu spec. It is a modern single cycle version with 62kB flash and 2kB of on chip ram (ADI's ADuC845).

[voltsandjolts]

sdcc seems to provide int64_t on 8051

Or are you also secretly specifying compiler as Keil C51 

[PCB.Wiz]

sdcc seems to provide int64_t on 8051

Yes, it says

Mar 1st, 2018: SDCC 3.7.0 released.
SDCC 3.7.0 Feature List:
64-bit integers (long long) for the mcs51 and ds390 backends (now long long is fully supported in SDCC except for the pic14 and pic16 backends).

and also shows some types - just PIC14/16 lack this
Some features of this standard are not supported in some ports:
• pic14, pic16: there is no support for data types long long, unsigned long long, int_fast64_t, int_least64_t, int64_t, uint_fast64_t, uint_least64_t, uint64_t.

There are hints in the names that _fast and _least may be potential for speed / size ? optimised, but the code seems to just alias all those to long long ?


Has anyone tried that ? Does it include + - * / ?

[PCB.Wiz]

It runs 32bit floating point, the 64bit int or floating point is not available, and the decNumber does not fit in.. 

What is your decNumber, and how do you use it ?

[GromBeestje]

_fast and _least are part of the C99 standard.
It allows for smaller types to be extended to the word size of the machine, so it ain't applicable to an 8 bit machine and is expected to be the same as the base type.

[ale500]

just curious, why ? what is your purpose ?
I work regularly with the 8051, in a much constrained environment as you (only 12 K OTP) and 640 bytes RAM. You cannot throw anything and it, it just chokes on everything that is not 8 bit and uses no pointers ...

[iMo]

It runs 32bit floating point, the 64bit int or floating point is not available, and the decNumber does not fit in.. 

What is your decNumber, and how do you use it ?

decNUmber is the famous C math library for arbitrary precision math. I was using it on stm32 mcus (like bluepill etc).
https://speleotrove.com/decimal/decnumber.html

[iMo]

just curious, why ? what is your purpose ?
I work regularly with the 8051, in a much constrained environment as you (only 12 K OTP) and 640 bytes RAM. You cannot throw anything and it, it just chokes on everything that is not 8 bit and uses no pointers ...

I want to do math with all bits coming from the ADC (24bit), the noise regardless. You cannot do it with 32bit ints (nor with 32bit floating point) easily. There is always something like 32 x 32b or 64 / 32b needed.
The chip I work with is pretty speedy and well equipped.. I am just trying with some 32x32b multiply and 64/32b divide routines, when ok no need for fractional math..
 

[PCB.Wiz]

I want to do math with all bits coming from the ADC (24bit), the noise regardless.
You cannot do it with 32bit ints (nor with 32bit floating point) easily. There is always something like 32 x 32b or 64 / 32b needed.
The chip I work with is pretty speedy and well equipped.. I am just trying with some 32x32b multiply and 64/32b divide routines, when ok no need for fractional math..

arbitrary precision maths is likely to be very slow, and too general anyway.
If you need headroom, IIRC I have seen ASM muldiv routines that do 32x32/32 with the interim as 64 bits (so you avoid needing a native 64 type)  *

You should check what ENOB your ADC actually has, as floating point is usually enough for 24b ADCs as the last few bits wave in the wind.

* Dug into the archives and found attached. Not quite muldiv 32*32/32 but easy to get to there....

Code: [Select]

MUL16_16_32:    ; Fast 16*16 -> 32 R7.R6 * R5.R4 -> R3..R0  Just 66 Cycles LP51 

MUL32_32_64:  ; 32b*32b-> 64b,  R7..R4:32 * ?X:32(IDATA) ->  RB1[R7..R0]:64 (or any 8 byte IDATA)
Size_MUL32_32_64 = 0x3a = 58 bytes,
; Time, No Exit : 1223  Early exit = 535 Test is 0x44332211*0x55443322 = 0x16B72583F017E942

Div_32d16r16:

Div_32d32:   ; now R0_Long.32/?X.32 -> R0_Long.32  LSB is lowest Adr.
; * Fix shift left, so R4_Long is REM.
; SPEED:   Cyc: 1588 Test =>  R0_Long 0x4326, R4_Long 0x7760 = correct Siz_Div_32d32  78 in ?Y, 69 bytes in R3..R0

Div_64d64:   ; RB1.R0_QWord.64/?X.64 -> RB1.QWord.64 REM RB0.QWord.64 LSB is lowest Adr.
; Changes RB1.R0_QWord, RB1.QWord.64, preserves ?X
; in Line  => 0x85 = 133 Bytes               6037  cycles test case, (vs 69 bytes in 32/32) ~302us @ 20MHz
; Call SL  => 0x72 = 114 (saves 19 bytes)    7069  cycles test case, (17% slower, 1000 more cycles)

Attached