Hello,
is there a way to initialize a floating point constant (code memory) with a raw binary value? Because we use a few special NAN flags and I cant initialize them using the CX51 compilier. With the IAR compilier I used a union and specified if the value should be interpreted as integer or floating point but with the CX51 compilier this is not possible for constant values because the compilier does not support this kind of initialization. It is part of C99 Standard but CX51 is C90. Maybe there is another way to do this.
Best regards
The union hack, while easier to control in C99, is also possible in C90. All you have to do is fix the order of element declarations in the union such that the one you're actually going to initialize comes first:
union hack { uint8_t bytes[sizeof float]; float val }; const union hack hackedval = {{1, 2, 3, 4}};
For similar information, you could have just looked up 'nan' in the C51 documentation.
That said, this union hack is quite rightfully frowned upon in civilized code (and outright forbidden in most industry coding rules). On top of that for the particular case at hand it's most likely pointless anyway, because there's very little chance that NaN handling with all its traps and pitfalls fully works in C51, which has to do it all in software, so it does have to cut some corners to arrive at anything resembling useful performance.
thanks for the answer. I know this is not the cleanest way but save me a lot of memory. I have my own NaN handling algorithm and check for NaN before I interact with library functions. Unfortunately I have to initialize both float and integer, so this is not a solution for me. Maybe there is another way?
nbp said:I have to initialize both float and integer
What do you mean by that?
I mean I have for initialize the union with both float and integer.
For example:
union hack { uint32_t i; float f; }; const union hack[3] = { .i = 0x7FC00008U, .f = 1000.0, .i = 0x7FC00001U };
Then you're going to have to take my approach to find out what the required bit pattern is.
yes you are right. I convert the float to an integer in a prebuild step.
However it would be great if Cx51 would support C99 in an upcoming version. The competition is better here.
I rather doubt that C51 is a priority for Keil - an ARM company - these days ...
;)
Remember that you're working on a target that has no FPU. That means almost every activity you perform on a floating-point value, unless it's completely optimized out by the compiler, is handled by calls to (hidden) runtime library functions. I.e. "before I interact with library functions" may be a lot earlier than you think.
If copy is a real copy than I have no problem. The code is already running on an Cortex M0+ which has also no FPU.
I only miss a compilier which supports C99. Maybe sdcc or iar is a better solution for future if the ARM company is not interested in the further development of the tool chain. Given the age of the C99 standard, this can be assumed.
Given the age of the '51, it can be assumed that it won't be bothered by such new-fangled nonsense :-) Forcing C90 down the throat of this antique is hard enough.
A challenge that others have already made. ;-)
Supporting designators would definitely not break anyone's fingers. That would make initialization of structs a lot easier, more readable and the best thing is it has nothing to do with microcontroller architecture, right?