[Top][All Lists]

[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 

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]