chprintf() show special values (float)

[Thargon]

Hi,

chprintf() does not print special float values (i.e. INF, NAN) appropriately, yet.
I have already created a patch that introduces this feature. The patch is based on a slightly outdated revision of the stable_20.x branch, but I do not expect any conflicts.

Btw, is there any chance to get 64 bit integers working correctly with chprintf()? There seems to be some issue with arguments larger than 4 bytes, but I could find the root cause of this.

Thomas

[Giovanni]

The issue would be bringing in 64-bits math from libraries on small targets, chprintf() is not meant to be fully compliant, FP support is already an "extra".

Giovanni

[Thargon]

I see that 64 bit support may cause extra trouble.

As for the FP output feature: It's really only very few lines of code and can provide very helpful information, imho.
If you don't want to include the extra math.h header, the three used methods 'isfinite()', 'isinf()' and 'isnan()' can be easily implemented manually, as it its just checking some bits:

Code: Select all

#define FP_SGNMASK     0x80000000
#define FP_EXPMASK     0x7F800000
#define FP_FRCMASK     0x007FFFFF

#define isfinite(f)    ((f & FP_EXPMASK) < FP_EXPMASK)
#define isinf(f)       (((f & FP_EXPMASK) == FP_EXPMASK) && ((f & FP_FRCMASK) == 0))
#define isnan(f)       (((f & FP_EXPMASK) == FP_EXPMASK) && ((f & FP_FRCMASK) != 0))

I would assume that people who enable FP support for chprintf() are fine with the extra ROM cost and appreciate the conveniences of this feature.
Performance should even be better for those INF and NAN cases, since printing a short classification string (e.g. "nan") is much faster than printing a long value string (i.e. "0.000000000"). For all other cases, it's just an additional call of 'isfinite()', which is just 2 clocks + jmp.

[Giovanni]

The above code does not look portable, it makes assumptions on the FP format being used.

Giovanni

[Thargon]

That code applies to IEEE 754 single-precision floating point specification.

I'd assume that all modern MCUs, compilers and software libraries follow that IEEE standard, but there might be exceptions. If those exceptions are an issue for ChibiOS, using the standard library 'math.h' header should be the preferable way, as that should take care of any platform specific attributes.

In any case, the overhead for detecting these special float values is minimal and should be no issue for anyone, who enables chprintf() float support.
Introducing this feature to ChibiOS is a no-brainer, imho, but in the end, it's your decision

- Thomas

[Thargon]

Just a minor update on compatibility: According to the C standard, floating-point arithmetic shall comply to the IEC 60559 floating-point standard. Even though exceptions are possible by setting the feature macro '__STDC_IEC_559__' to 0, that would break binary compatibility etc. and is thus not officially supported by the C standard.

Floating-point binary representation as defined by IEC 60559 is identical to the definition in IEEE 754, so as long as '__STDC_IEC_559__' = 1 holds, my code above should be compatible.
Personally, I would still prefer to use the 'math.h' header, so we don't have to care about those details.

[Giovanni]

Math.h is not a problem, including an header does not increase code size in itself.

Doing any operation in double precision would increase code size because double precision code would be linked from math libraries.

Giovanni