<jason-kairos[m]>
nevermind, needs to be launched with rust-gdb wrapper
<therealprof[m]>
therealprof[m]: The log functions are intrinsics already so it's not quite clear to me why they couldn't be added to the primitive types in core.
<dirbaio[m]>
the writer.needs_full_strings() condition is itself a dyn call so the compiler can't predict it, so the final asm will contain both branches of the if, including the full string
<diondokter[m]>
Hmmm... you might be right yeah
<dirbaio[m]>
it is possible for the compiler to devirtualize then inline then dead-code-eliminate but it's not guaranteed..
<dirbaio[m]>
maybe you can make it instead a Cargo feature in core or something, to switch the whole compilation to "use interned strings only" mode
<dirbaio[m]>
but then things like write!() into a heapless string would break
<diondokter[m]>
dirbaio[m]: I've thought about something like that. But that won't work
<diondokter[m]>
dirbaio[m]: Yeah this
<dirbaio[m]>
tldr I don't see how can you mix interned and noninterned writers in the same compilatino
<dirbaio[m]>
s/compilatino/compilation 🥲/
<diondokter[m]>
Hmmmm... I need to think about it more it seems
<diondokter[m]>
Deferred formatting is still possible though
<diondokter[m]>
But getting that properly optimized may also be complicated by dyn
<dirbaio[m]>
yeah...
<diondokter[m]>
Here's a fun fact btw: Rust fmt is made for performance, right?
<diondokter[m]>
If you format a float, say `12.34`, that will result in 3 calls to the `write_str` function with: "12", "." and "34"
<diondokter[m]>
I get why, but it seems silly :P
<dirbaio[m]>
lol
<dirbaio[m]>
i don't want to discourage you but
<diondokter[m]>
Haha
<dirbaio[m]>
if the goal is to fix the defmt/fmt ecosystem split
<dirbaio[m]>
this has to match defmt in code size
<dirbaio[m]>
which ... yeah
<diondokter[m]>
I disagree. It's all about pros and cons. If fmt was only 10% of its current size, I don't think defmt would've existed (or at least been so prolific)
<dirbaio[m]>
we don't live in that timeline tho :D
TomB[m] has joined #rust-embedded
<TomB[m]>
dictionary formatting is always useful for small devices, even when you have compact string formatting code
<TomB[m]>
at least from what I've seen in Zephyr, the string formatting stuff adds up fast
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
Compile time reflection for fmt like in facet is a neat idea but the facet types are huge
<i509vcb[m]>
I think on aarch64 the main Facet type is 200+ bytes per type
<i509vcb[m]>
I think the issue there is facet is trying to do a everything on a single type, which means a single usage pulls in hundreds of bytes of metadata that isn't needed or used likely.