[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Interested in 64-bit printf support?
From: |
George Spelvin |
Subject: |
Re: [avr-libc-dev] Interested in 64-bit printf support? |
Date: |
5 Dec 2016 19:36:02 -0500 |
[Re-send to list this time.]
Thanks for the reply! I know this is a minimal-time hobby for you and
I'll try not to be a pest. But some response is very motivating.
> Basically, yes, having 64-bit integer printing support in vfprintf()
> would certainly be cool.
Okay, great! I'll start working in that direction. Step 1: check out
avr-libc into git-svn and build it.
> My only concern from avr-libc's point of view would be how to enable
> this. So far, we've got three different link-time options for
> vfprintf(), "standard", "reduced", and "floating-point". If we add
> the 64-bit support to the latter (in the sense of "full-featured"), it
> might hit people who are really only intersted in floating-point
> support. OTOH, people who are actually only interested in 64-bit
> integer formatting would be forced to also take the load for FP
> support.
I suggest adding it to "standard". It would add *very* little code.
As I mentioned, the cleanest way to do this is to change the argument
handling in vfprintf() to use a pointer & size (to the argument on the
stack), rather than a copy of the value. That actually shrinks the
code and register pressure inside vfprintf() slightly. Then all you
need to do is add code to parse %ll and learn that it means "length=8".
The only overhead is needing a 20-byte (or 22-byte, for octal) buffer
on the stack, rather than the current 11-byte one. If that's a problem,
I can do a bit of extra work to get around that:
I change the calling convention so that the caller doesn't pass in a
buffer pointer, but a FILE * and some precision+flags. Then the
formatting code *pushes the number on the stack* and calls
vfprintf_helper(FILE *, char *ptr, uint8_t len, uint8_t prec, uint8_t
flags)
vfprintf_helper() supplies the necessary prefixes based on the precision
and length, makes the necessary fputc() calls, then the buffer gets
deallocated when it returns.
I can't find a way to tail-call vfprintf_helper() and teach it to do
the deallocation itself (I can add my own asm() block ending in ret,
followed by __builtin_unreachable(), but that would omit the helper's
epilogue to restore spilled registers), but if you really need to
save stack I can do the whole helper in asm.
- [avr-libc-dev] Interested in 64-bit printf support?, George Spelvin, 2016/12/04
- Re: [avr-libc-dev] Interested in 64-bit printf support?, George Spelvin, 2016/12/05
- Re: [avr-libc-dev] Interested in 64-bit printf support?, Joerg Wunsch, 2016/12/05
- Re: [avr-libc-dev] Interested in 64-bit printf support?,
George Spelvin <=
- Re: [avr-libc-dev] Interested in 64-bit printf support?, Georg-Johann Lay, 2016/12/06
- Re: [avr-libc-dev] Interested in 64-bit printf support?, George Spelvin, 2016/12/06
- Re: [avr-libc-dev] Interested in 64-bit printf support?, George Spelvin, 2016/12/06
- [avr-libc-dev] I just noticed OPTIMIZE_SPEED, George Spelvin, 2016/12/06
- Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED, Joerg Wunsch, 2016/12/06
- Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED, George Spelvin, 2016/12/06
- Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED, Joerg Wunsch, 2016/12/07
- Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED, Georg-Johann Lay, 2016/12/08
Re: [avr-libc-dev] Interested in 64-bit printf support?, Georg-Johann Lay, 2016/12/07