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
chprintf() show special values (float)
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: chprintf() show special values (float)
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
Giovanni
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: chprintf() show special values (float)
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:
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.
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: chprintf() show special values (float)
The above code does not look portable, it makes assumptions on the FP format being used.
Giovanni
Giovanni
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: chprintf() show special values (float)
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
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
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: chprintf() show special values (float)
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.
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
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: chprintf() show special values (float)
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
Doing any operation in double precision would increase code size because double precision code would be linked from math libraries.
Giovanni
Return to “Small Change Requests”
Who is online
Users browsing this forum: No registered users and 17 guests