Looking at GCC's assembly output, I was disgusted by what it was doing
(note that I'm still using avr-gcc 4.9.1) and wrote an assembly version.
That let me do some useful space-saving tricks like allocating a different
zero register so that r1 is free for the multiplier.
Again, feel free to kibit
As George Spelvin wrote:
> I could just pass this over to the TICC project, but is there any interest
> in me making the necessary overhauls to vfprintf to incorporate this?
Basically, yes, having 64-bit integer printing support in vfprintf()
would certainly be cool.
My only concern from avr-lib
[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
As I'm looking through the rest of the code, I notice a few silly things.
For example, couldn't rand_r save a jump by declaring it
int rand_r(unsigned long *ctx) __attribute__((alias("do_rand")));
But the real problem is the choice of algorithm.
32x32-bit multiplies are very ugly and bloated on
As George Spelvin wrote:
> I suggest adding it to "standard". It would add *very* little code.
That's even better to hear.
> 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 cop
As George Spelvin wrote:
> As I'm looking through the rest of the code, I notice a few silly things.
>
> For example, couldn't rand_r save a jump by declaring it
>
> int rand_r(unsigned long *ctx) __attribute__((alias("do_rand")));
I don't think that would work, as do_rand() is declared "static
