fix fractional floating point values on platforms where unsigned < 64 bits

[mateoconlechuga]

Our platform is an odd 24 bits - so this bug was discovered.

[charlesnicholson]

Ha, wow, that's cool. Are you saying that the unsigned type on your architecture is a natural 24 bits?

[mateoconlechuga]

Yes that's correct - it's an eZ80 platform

[charlesnicholson]

Thanks for the fix! I'll cut a release from this if it's helpful. (I think it was always a bug!)

[mateoconlechuga]

Awesome, thanks for the nice printf :)

[charlesnicholson]

Oh, please add an entry to the contributors file at the root if you want. People usually put their github id's but anything you want is fine. (If you don't want to, don't worry about it)

[mateoconlechuga]

That's all right haha, I didn't add too much

[charlesnicholson]

Will cut a quick release now, hang tight

[charlesnicholson]

oh btw i'd be very curious to hear npf binary size numbers on your arch if you have them handy! nbd if not, always just curious to see how it does on new platforms :)

[charlesnicholson]

https://github.com/charlesnicholson/nanoprintf/releases/tag/v0.3.1

[mateoconlechuga]

Sweet, thank you :)

Currently it is 7670 bytes, we are compiling with ez80-clang, a backend we've been writing for specifically for the TI 84+CE calculators (toolchain here). Hopefully with more compiler modifications we can continue to drop the compiled size.

We are using a slightly modified version of nanoprintf here.

[charlesnicholson]

Wow, that ended up being pretty huge. I shipped a Gameboy Color game on the Z80 ~25 years ago but it was 100% asm. I'm honestly kind of amazed that compilers are good enough to eat nanoprintf and emit working Z80 insts!

[mateoconlechuga]

Yeah the size is probably because there's no hardware instructions for floating point and 64 bit math gets pretty big in software. But it's definitely been getting better over time.

The Z80 is definitely a fun platform - the calculator scene definitely has a lot of people from the gameboy programming days as well!

Thanks for the merge!

[charlesnicholson]

Thinking it over, I wonder how much impact it would have to size on your platform if we changed the various u64's to u32's for floating point processing? Obviously it would lose some range and we'd need some truncation code but I imagine doing anything 64-bit incurs huge penalties on 8-bit micros hahaha :)

[mateoconlechuga]

Yep that is true :) A compile-time option would be pretty handy maybe?

[charlesnicholson]

Unsure when I'll get around to it but I'll file an issue to explore it. Here at nanoprintf we do enjoy compile-time flags :-|

[charlesnicholson]

Also I'm guessing you've discovered it but you'd probably pay a very large penalty if you set NANOPRINTF_USE_LARGE_FORMAT_SPECIFIERS to 1. We start getting into intmax_t territory which is big.