How to create FMU source code for Linux 64 in windows with LONG_MAX set to 64 bit

24 views (last 30 days)
Creating an FMU with Hardware Implementation 'Device Vendor' set to either 'AMD' or 'Intel' and 'Device Type' to be 'x86-64 (Linux 64)' generates C code with a compile check for 32 bit "long" data type.
#if ( ULONG_MAX != (0xFFFFFFFFU) ) || ( LONG_MAX != 0x7FFFFFFF) )
Even tried with different toolchains for embedded Linux 64 bit.
Is it not possible via FMU to create C code for Linux 64 bits where "long" is 64 bits?

Answers (1)

Andy Bartlett
Andy Bartlett on 17 Oct 2022
Edited: Andy Bartlett on 18 Oct 2022
Simpler need
If you're goal is just to have the size of long defined as 32-bits in the generated code, then you can change the settings on the Hardware Implementation pane of your Configuration Parameters dialog of your Simulink model (or similar dialog in MATLAB Coder projects). Click the toggle "Device Details" to see what size is being used for long in the generated production code.
Linux 64-bit is an LP64 architecture and will always define long as 64-bits. To get long to be 32-bits you want a different architecture such as 64-bit Windows which is LLP64, or you can choose custom on the Hardware Implementation pane and explicitly set the individual word lengths for the five integer types.
Note: I suspect you'll want to check the box on the Hardware Implementation pane "Support long long" so that you will have a 64-bit integer type available.
More complex need, portability
If you are seeking to get generated code that can be recompiled for both Linux 64 and Windows 64 without re-generating the code that is harder.
The C and C++ languages are not designed to be portable with regard to the size of integers. MathWorks Coders take care to make sure that integer and fixed-point code have bit-true agreement with simulation behavior. Coders also seek to make the generated bit-true code as performant as possible for the target for which code is being generated. Compiling that code on a target with different sizes for any of the 5 integer types could lead to incorrect behavior.
The preprocessor checks of integer max values are designed to make sure that code does not silently give incorrect answers due to compiling code intended for a "target A" on a "different size target B".
The Portable word sizes feature is intended to provide code that supports two slightly different targets. One target is the Production Target as defined on the Hardware Implementation pane. The other target is the current MATLAB Host. This feature may solve your problem. If you configure the production target to be an LP64 and generate code on an LLP64 MATLAB host or visa versa with "support long long" on, you can expect Portable word sizes feature to modify the code to avoid depending on the size of long which would vary between 32 bits and 64 bits.
There is also a "remove the safety rails options." As described on this doc page,
set_param(gcs, 'TLCOptions', ...
This will remove the preprocessor check, but there could be silent disagreements with simulation depending on what the code contains. For example, a literal constant like 34LU may be treated as 32 bits on one platform and 64 bits on another. This could lead to silent changes due to C and C++ usual binary type promotion rules and overflow behaviors.


Find more on Code Generation in Help Center and File Exchange





Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!