Introduction

As provider of computational solutions, we recently had several projects, where we had to assess whether C/C++ code could be generated from a MATLAB code base. The algorithms had to be embedded, so it would be convenient to reuse the existing code base and “just” make it Coder-compatible - suitable for code generation using MATLAB Coder. In most cases, we found a migration towards Coder-compatibility was achievable, but in some cases a significant effort would be required.

In a series of blogs, we like to share our experiences. We will discuss various aspects of the assessment process, look into the process of upgrading an existing code base towards a Coder-compatible one, give tips and elaborate on the benefits the “Code Checker for MATLAB” adds to this process. With that we think the big hurdles can be reduced to “just another development step".

First, we look why code generation from MATLAB M-code is still more a niche, especially when compared to the use of code generation from Simulink models, which is the de facto standard in control applications. We can understand this, when looking at all the possible options for deploying a MATLAB algorithm. There are four options, listed below and visualized in Figure 1. MathWorks themselves only mentions the first two options on their website:

Fig.1 - Options to deploy a MATLAB algorithm.1

1. Code generation via Coder technology² . Although the main use is generating C or C++, this technology is also used to generate (V)HDL, CUDA, and structured text (PLC software).
2. Runtime-engine based deployment using Compiler technology, this includes creating platform-specific standalone executables and libraries, MATLAB Production Server, Excel plugins, etc. ³
3. MATLAB running on the deployment target. This is mentioned as a valid option by Dr. Edelhofer from MathWorks.
4. Manual translation.

First, the Compiler technology will be discussed. As the compiler technology includes a runtime engine, from our perspective this is like using MATLAB itself (the option from Edelhofer). After that, a few notes will be made on manual translation and at last we look at Code generation.

MATLAB Compiler convenient?

Deploying with MATLAB, or using the MATLAB Compiler technology, comes with little or no extra effort for making the code ready for deployment. If not deployed to the cloud, the Compiler technology allows various approaches for integrating the application on the target platform itself. Server-based deployment – in the cloud or on premises - is very convenient in case of web-applications and putting analysis close to data sources (that are in the cloud as well). Furthermore, depending on the exact deployment method, the graphical MATLAB elements (plots and user interfaces) are supported as well.

Overall, the Compiler technology looks like the preferred approach, but the technology comes with strings attached. We name three major drawbacks.

1. The integration with structured data is not trivial, even in well-known languages as C/C++ and C#. So, although the effort on the code base itself is low, the integration effort still can be significant when combined or integrated with complex (nested) data structures.
2. The need for heavy, platform-specific components (a MATLAB, MCR or worker installation) is undesirable in many setups. It even might be a show-stopper in case of an unsupported platform or limited resources.
3. Maybe the most prominent issue we faced with the Compiler technology, is the closed nature of many of the underlying components. In case of problems (like undocumented limitations) in the deployed applications, you are totally dependent on the support from MathWorks. Although they provide professional support, the need to provide the MathWorks with a simpler example that has the same problems is a (time-consuming) challenge on its own, given limitations on IP and data security. In case no workaround can be provided, you will have to wait for a fix in the future.

Still, the typical route for deployment is the Compiler technology. But even in case it can be used from technical point of view (platform is supported, or cloud-based deployment is an option, or even desired), there might be reasosn to choose different. Resource requirements, timing constraints, closed source elements, security, or license costs may still result in a choice for using Coder technology or manual translation.

Manual translation still used!

Benefits of manual translation are the fresh look of a new developer and the possibility to include platform-specific solutions. Both these benefits can apply to an auto-coding workflow as well by having a good review process and integration of target-specific code. The drawbacks of manual translations are well-documented by a.o. MathWorks in various model-based design publications and marketing materials. We may say that, overall, it is accepted that code generation from low-code and fourth-generation programming language specifications is efficient and drives the quality of a project. The executable specification (a golden reference) is automatically translated into the implementation, removing both the gap and inefficiencies between specification and implementation. Furthermore, because of the increasing complexity and size of algorithms, the required effort for manual translation becomes too big to be affordable and manageable. Therefore, manual translation can only be considered a valid option when code generation is not possible (yet) or when the Compiler technology is not desired.

Adoption of code-gen still low

Even given the alternatives for code generation from MATLAB, and the fact that the Coder technology is relatively new for MATLAB code (compared to code generation from Simulink’s graphical models), the use of code generation is still not as common as expected. One of the main reasons not to use the Coder technology for complex MATLAB algorithms, is the effort to write Coder-compatible MATLAB code. For new projects this can be managed from the start, but for a large existing code base this poses a problem. Most companies do have such an existing code base. Migration towards Coder-compatible MATLAB code can be problematic. Reason is that even some constructions with architectural impact are not (yet) supported by the Coder technology. For example, it is allowed to change a structure layout during its lifetime and in case of an array of structures, the same field is allowed to contain differently typed data over the various array elements. All this flexibility is not supported when generating code. Also, migrating a class (OO-programming) is a real challenge when Coder-compatibility was not considered from the start. Effectively, this reduces MATLAB from a fourth-generation language (coding from functional needs) to a third-generation language (like C, with the need for much more software-specific details like explicit data typing and declaring variables).

Our following blogs will lower the barrier and help in solving or even preventing the technical issues so that MATLAB still can be used for designing algorithms, even with code generation for deployment as final goal. As one of the main issues is that a large amount of MATLAB code is not yet Coder-compatible, the next blog will be about assessing an existing code base for compatibility and the added value of the Code Checker for MATLAB.