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

[Harald Kipp]

Hi Uwe,

On 23.09.2013 20:02, 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?

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

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


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

Believe me, it was. The 32 byte tables significantly reduced the code
size. Now we have 64 bytes more, which may change the 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 .

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

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

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

Right now I cannot see, why adding something like
NUT_EXCLUDE_64BIT_SUPPORT should be difficult to implement. But, as I
said, you are probably more familiar with the hidden 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.

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

Regards,

Harald