64bit Integer Support?

skeller

I am researching the Propeller 2 for a commercial project. It has some very compelling advantages over a standard 32bit microcontroller like an STM32F4. However, being that it is somewhat a "boutique" device ( I do not mean that in any negative sense) there doesn't seem to be a lot of library support.
I am looking for, but haven't found it yet, support for 64bit Integers, both signed and unsigned. Is there support out there for the P2 and I just haven't found it yet?

It looks like ethernet has been done using the ENC28J60, I assume there is a basic TCP/IP stack to go along with it.

evanh

Not so far.

My guess is you're wanting the higher precision in maths ops while retaining the speed of integers. Ie: Stored values are okay as 32-bit but multiplication overflow and division rounding desire the higher 64-bits ... for that there is a reasonably convenient function called muldiv64(). It multiplies then divides with a 64-bit intermediate using two Cordic ops.

Further reading - https://forums.parallax.com/discussion/comment/1531785/#Comment_1531785

pik33

Yes, we need both int64 and double. They are not implemented neither in Propeller Tool, nor in Fllexprop. We can write a library, maybe it is already written, I don't know, but it is only a workaround...

avsa242

I asked if this would be feasible to implement in spin awhile ago... there's a thread somewhere here. IIRC, the answer wasn't an outright "no", but that it'd take a lot of work and couldn't give a definitive timeline on it. I think both Chip and Eric answered (for the Parallax and Flex compilers, respectively).

PropGuy2

I did some coding work a few months ago and got some "discontinuities" in the MultDiv64 function. There is a 2 to 3-percent rounding error somewhere in this 64-bit function. There is a thread in forums that addresses this error.

skeller

Thanks for the info.

I don't see any official library support for 64bit values in the older P1. With as long as the P1 has been around I guess I won't hold my breath on something becoming available for the P2.

I did see in the PASM2 manual it addresses Multi-Long Add/Sub/Cmp. The use case for this is weight accumulators that accumulate values for the lifetime of the product (10+ years). So it needs to maintain its precision but be able to accumulate very large values.

@PropGuy2 - I did find the issue regarding MultDiv64 function, @evanh linked to a post that refers to it. For the quick jump it's here: https://forums.parallax.com/discussion/comment/1525687/#Comment_1525687

Ariba

@skeller said:
...
I did see in the PASM2 manual it addresses Multi-Long Add/Sub/Cmp. The use case for this is weight accumulators that accumulate values for the lifetime of the product (10+ years). So it needs to maintain its precision but be able to accumulate very large values.
...

You can do some 64bit calculation with inline assembly:

CON
   _clkfreq = 180_000_000

PUB main() | v, AccuL,AccuH
  AccuL := AccuH := 0
  repeat 1000
    v := getrnd()           'a random 32bit value
    org
      add   AccuL,v   wc    'add to 64 bit Accu
      addx  AccuH,#0
    end
  debug(uhex_long(AccuH),uhex_long(AccuL))

Andy

ersmith

64 bit integers are supported in some C compilers, e.g. PropGCC (for P1) or riscvp2 (for P2).

ManAtWork

How much work would it be to implement 64 bit integers in FlexC?
If operator methods of C++ were implemented everyone could write a library that supports 64 bit operations. But I guess that would be even more work for you.

ersmith

@ManAtWork said:
How much work would it be to implement 64 bit integers in FlexC?

It's a medium amount of work, and it's slowly been coming along. You can actually declare 64 bit integers with "long long" even now, and very simple operations with them work, but a lot of things don't work yet. It's hard to overcome the "everything is 32 bits" mindset of Spin, which survives even now in FlexC (which started off as a Spin compiler).

If operator methods of C++ were implemented everyone could write a library that supports 64 bit operations. But I guess that would be even more work for you.

Yes... operator methods would be very nice to have, but it will complicate the type system by a lot, so they will not be appearing any time soon.

JRoark

@ersmith Pssst. Double precision. 😜 (hey, I can dream!)