Add support for double / long double

[mateoconlechuga]

Currently doubles are aliased to floats. This could probably be changed in the future if enough people care, as well as adding support for long doubles.

[pacmancoder]

@mateoconlechuga Hi, I was trying to compile wasm3 project (just for fun) And looks like the only thing that is missing with the current CE llvm/toolchain is long long support (It may still potentially crash due to only 4K stack after that, though). Specifically, these rt functions are missing:

_llcmpzero
_lladd
_lland
_llxor
_llcmpu
_llshl
_llshru
_llshrs
_llor
_llsub
_llremu
_llrems
_lldivs
_lldivu
_llpopcnt
_llmulu

Is there anything that I can clutch to make these functions work? Is there is still any possibility that long long support may land in llvm/toolchain in some observable future?

[adriweb]

Reminder that you only have 4 KB of stack and around 60 KB of heap. You are nowhere near able to get something like that running on this platform :P

[pacmancoder]

@adriweb yeah, I know, however, it will be really interesting if this indeed will work (I believe wasm3 runtime itself has only ~10K heap footprint, the only thing which really concerns me is a stack usage (which all around the place). But if it will be capable of outputting a few numbers from Fibonacci sequence, then I see this as an absolute win 🤣

[adriweb]

Well, that's better than I expected, but we'll see.
Regardless, there's another limitation that can be troublesome. One program can only be 65k or less, otherwise there are some tricks to ahve it split in multiple appvars (which can also be up to 65K) then launched via a loader. But then watch out for RAM in general...
Anyway, first, it would need to be compiled with long long stuff....

[mateoconlechuga]

long long wouldn't be as hard as adding proper double support, but still would be a pain. Probably not something that is going to make it in the observable future, at least not in the next couple months (years?), so who knows.

[runer112]

Not going to mess with doubles (for now), but I've been working on optimizing a lot of integer math functions and adding long long versions.

[vshymanskyy]

Wasm3 can be compiled without float/double support, i.e. -Dd_m3HasFloat=0. If you have 4K stack, 60K heap, and your TEXT section executes from Flash (not RAM)... And if it fits your flash => you should be able to run Wasm3 :)

UPD:
Also, you cannot just alias double to float, as it would break the memory layout of the running wasm module. But it shouldn't cause any major issues on interpreter level, AFAIK. It's saver to disable floats, which would also decrease the code size, etc.

Let me know if I can help here, I'd really love to see Wasm running on TI-84 Plus CE.

The TI website says it's:

3 MB FLASH ROM memory for data archive and storage of apps
149 KB of available RAM memory

With such specs, it's more than capable of running Wasm3.
Wondering why it says 149 Kb, and you mentioned 60 Kb of heap?

[runer112]

Wondering why it says 149 Kb, and you mentioned 60 Kb of heap?

The device actually has 256KB of RAM, but the regions of memory that are free to use without stepping on anything else are limited, fractured, and potentially dynamic. The heap currently occupies the largest available contiguous section of RAM that should always be free to use.

[mateoconlechuga]

Ideally you could overwrite the OS and run whatever you wanted; but it would no longer be a "calculator" in anything but the physical appearance -- which would still be pretty awesome :)

[vshymanskyy]

Ok, in any case 60K should be more than enough. Wasm3 is running in some devices with 16K RAM total, i.e. nRF51 series. It was also running (to some extent) on 8bit AVR ATmega1284.

[mateoconlechuga]

@vshymanskyy In other news, 64 bit support is almost complete and wasm3 is able to do fib(24) on the calculator:

fib32:

fib64:

The binary is about 33K compressed (compression saves 63%).

[adriweb]

Done with #354 being merged

[runer112]

A lot of the recent activity on this issue kind of hijacked it, making it about 64-bit int support. But the original issue text and title are about 64-bit (or higher) float support, which has not been implemented yet. So I'm reopening this issue.