[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 Uwe, On 23.09.2013 20:02,
    Harald> bon at elektron.ikp.physik.tu-darmstadt.de wrote:

    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?

    Harald> As far as I understood, the problem appears only with 64-bit
    Harald> arguments.  Did I miss something?

    Harald> If not, then I think that an increase of 750 bytes for code and
    Harald> 36 bytes of RAM is too much for existing programs, which didn't
    Harald> use any 64-bit values.


    >> Anyways, the original code also was not written with RAM/Flash
    >> starving AVR8 in mind:
    Harald> ...
    >> 
    >> already put blanks and zeros into RAM for AVR8.

    Harald> Believe me, it was. The 32 byte tables significantly reduced the
    Harald> code size. Now we have 64 bytes more, which may change the
    Harald> proportion.


    >> 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 .

    Harald> You've been working on this and probably a deeper insight.

    Harald> My motivation is, that I see growing the code for the same
    Harald> application year by year. Many people argue, that this doesn't
    Harald> matter, because memory and CPU power becomes cheaper. Reality
    Harald> is, however, that at least 2 projects I know of are unable to
    Harald> upgrade because of increased memory requirements. As a result, I
    Harald> would have to create new bugfix releases in the 4.10 and
    Harald> possibly even in the 4.8 branch. And I really hate wasting my
    Harald> time on that old code.

    Harald> That's why I recently started to carefully watch the code size.
    Harald> Unfortunately I do not have sufficient time to do this right
    Harald> after every patch and therefore asking every developer to have
    Harald> an eye on this issue.

    Harald> Right now I cannot see, why adding something like
    Harald> NUT_EXCLUDE_64BIT_SUPPORT should be difficult to implement. But,
    Harald> as I said, you are probably more familiar with the hidden
    Harald> problems of such an approach.


    >> 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.

    Harald> I'm definitely more concerned about the additional 700+ of code
    Harald> space.

I have code in petto. Need to test...

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

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