Add an option to disable float64 from the generated code

[TYuD]

Hello! I suggest to add an option to disable sections with float64 from the generated code. Because this type is very bulky for some microcontrollers. It is desirable to enter the same option for float32, because some chips can only work with integer arithmetic.

It seems too strict a restriction to stop compilation by assert in cases where the compiler does not support float32 or float64. It is enough to exclude the corresponding sections of the code if the corresponding float type is not supported by the compiler. For example, using conditional compilation:

#if NUNAVUT_PLATFORM_IEEE754_FLOAT == false
   code with float32...
#endif
#if NUNAVUT_PLATFORM_IEEE754_DOUBLE == false
   code with float64...
#endif

If there are no fields with the floatXX type in the messages, which is not supported by the compiler, then there will be no errors during code generation. If the user wants to generate a code for messages with floatXX, an error will be issued.

Conditional compilation is quite compatible with transpiller options:

{% if not options.omit_float_serialization_support %}
    #if NUNAVUT_PLATFORM_IEEE754_FLOAT == false
        section of code with float32...
    #endif
{% endif -%}

But I would add two more options: omit_float32_serialization_support and omit_float64_serialization_support. The old omit_float_serialization_support option can be left for compatibility.

[pavel-kirienko]

@thirtytwobits would you accept a pull request implementing this?

[thirtytwobits]

Perhaps. Is it more correct to add this to the core specification and as a directive in the DSDL? I think it's better to find the violation when authoring DSDL then to wait until someone generates a given type for a given target.

[pavel-kirienko]

At this point, I would rather not touch the Specification with a ten-meter pole unless there are defects. Violations can be found with a linter script based on PyDSDL, kind of like https://github.com/UAVCAN/public_regulated_data_types/blob/master/verify (see also OpenCyphal/public_regulated_data_types#68)

[TYuD]

Take, for example, the C++ standard. Different compilers may not fully implement this standard. Compilers for DSPs and MCUs often exclude STL and RTTI. The standard itself is not being redone because of this. This practice is considered normal.

By analogy: there is a DSDL standard, and there are transpillers for specific systems. Transpillers may not implement the full DSDL standard. Wrong?

[thirtytwobits]

Okay. I'll buy it