[En-Nut-Discussion] Extending printf for handling 64 bit values

[bon at elektron.ikp.physik.tu-darmstadt.de]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hi list, I'm sure, that many developers wants to have this and
    Harald> it's great that Uwe implemented it and tested it on the Cortex.

    Harald> But there's a big problem with the current implementation.

    Harald> This simple program

    Harald> #include <dev/board.h> #include <dev/debug.h> #include
    Harald> <sys/heap.h> #include <stdio.h>

    Harald> int main(void) { NutRegisterDevice(&devDebug0, 0, 0);
    Harald> freopen("uart0", "w", stdout); printf("%d bytes free\n",
    Harald> NutHeapAvailable()); for (;;); }

    Harald> creates an AVR 8-bit binary of 6804 bytes and consumes 2020
    Harald> bytes of RAM. That's already an awful lot.

    Harald> When adding Uwe's 64-bit patch, the binary grows by another 748
    Harald> bytes and consumes an additional 36 bytes of RAM. Even if you
    Harald> don't need 64-bit values. I think this is too costly.

    Harald> When adding a new function, which consumes significantly more
    Harald> resources without actually using it, user should have to ability
    Harald> to disable this new feature via the Configurator.

Fixing silent argument corruption is a new feature?

Anyways, the original code also was not written with RAM/Flash starving AVR8
in mind:

#if !defined(__AVR__)
#define NUTCONST const
#else
#define NUTCONST
#endif
static NUTCONST char blanks[PADSIZE] = {
    ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ',
    ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ',
    ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ',
    ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '
};
static NUTCONST char zeroes[PADSIZE] = {
    '0', '0', '0', '0', '0', '0', '0', '0',
    '0', '0', '0', '0', '0', '0', '0', '0',
    '0', '0', '0', '0', '0', '0', '0', '0',
    '0', '0', '0', '0', '0', '0', '0', '0'
};

already put blanks and zeros into RAM for AVR8.

And with AVR8, STDIO_FLOATING_POINT and printing of 8-Byte units as
configuration variable, you have 9 possible combinations, easyly leading to
spaghetti code. Not a sensible option while originally hunting an bug in
another submodule .

But printing -1LL in octal only has 22 digits, and so 32 digit
padding are ample and one possible room for improvement. Will think about it.

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------