Matlab Generate Code

Generate Code with MATLAB Coder

Umbrella skill for the MATLAB Coder workflow: generate code, verify it, refine the config, and accelerate with profiled MEX.

When to Use

• Generating C/C++ or CUDA code from MATLAB functions (MEX, lib, dll, exe)

• Writing new MATLAB code that must be compatible with code generation

• Reviewing existing MATLAB code for codegen readiness or fixing codegen errors

• Configuring codegen settings for specific targets (embedded, speed, readability, safety)

• Verifying generated code matches MATLAB output (coder.runTest, matlabtest.coder.TestCase)

• Profiling and accelerating generated MEX functions

• Using coder.* directives (coder.varsize, coder.const, coder.extrinsic, coder.ceval, etc.)

When NOT to Use

• Simulink Coder / Embedded Coder Simulink-model workflows

• Generating code for target languages that are not C, C++, or CUDA

• Fixed-Point Designer conversion workflows

• Hand-written MEX C files (not generated by MATLAB Coder)

• General MATLAB programming unrelated to code generation

Route to a more specific skill

• Generating code from an AI model (PyTorch .pt2 / LiteRT .tflite via loadPyTorchExportedProgram / loadLiteRTModel) → use matlab-deploy-ai-model. Return here for the underlying coder.* directives, config tuning, and screener/verification.

• Deploying to physical embedded hardware (on-target PIL, ERT hardware configs, board selection — STM32 / Raspberry Pi / ARM Cortex) → use matlab-deploy-embedded-code. This skill covers host-side codegen, SIL, and config tuning up to hardware targeting.

• Speeding up interpreted MATLAB by rewriting the M-code (vectorization, preallocation, caching) → use matlab-optimize-performance. This skill's acceleration path assumes you want to compile to MEX/C, not restructure the algorithm.

• General MATLAB test authoring (parameterized tests, fixtures, mocking, App Designer) → use matlab-write-tests; for running suites, collecting coverage, and CI/CD → use matlab-run-tests. This skill covers only codegen-equivalence tests (coder.runTest, matlabtest.coder.TestCase).

• Modernizing deprecated APIs for currency/maintainability when code generation is not the goal → use matlab-modernize-code. This skill rewrites source only to satisfy codegen constraints, with explicit authorization.

Routing — load the matching reference file on demand

Pick the workflow that matches the user's intent and read the corresponding references/*.md. Each reference file is a deep, self-contained guide; load only what you need rather than carrying all four in context.

Disambiguation — "write" vs. "generate" vs. "generate for a class":

• "Write codegen-ready code" = authoring/reviewing the MATLAB source so it can be compiled (write-codegen-ready.md)

• "Generate code" = running codegen to produce C/C++ from an already-valid function (generate-code.md)

• "Generate code for a class" / "generate C++ class" = the user's source is a classdef file → load generate-code.md (Step 0 handles class entry points via coder.ClassSignature). Do NOT default to wrapping the class in a function.

• If both apply (user wants to write a function AND generate code from it), load write-codegen-ready.md first, then generate-code.md

For requests that span workflows (e.g., "generate MEX, verify it, then speed it up"), load the references in order rather than all at once.

Out of scope

• Simulink Coder / Embedded Coder workflows (these are skill candidates of their own).

• Non-C, C++, or CUDA target languages — this skill covers C/C++ and CUDA code generation only

• Fixed-point conversion (use Fixed-Point Designer).

• Hand-written MEX files — the acceleration guidance assumes MATLAB Coder-generated MEX.

• CodeExecutionProfiling / SIL profiling with Embedded Coder — out of scope for the acceleration reference.

Cross-cutting rules

These apply across every workflow. Apply them whether or not you've loaded a per-workflow reference yet.

Class entry point — use coder.ClassSignature, not a wrapper function

When the user's target is a MATLAB class (classdef file) and they want to generate C++ code from it, use coder.ClassSignature for direct class code generation. Do NOT create a wrapper entry-point function. This produces a proper C++ class with methods — which is what users mean when they say "generate C++ class."

Load references/generate-code.md → Step 0 and references/write-class-limitations.md → "Direct class code generation" for the full workflow. The prerequisite enableCodegenForEntryPointClasses must run once per session.

Only fall back to a wrapper function if the user's MATLAB version lacks coder.ClassSignature (pre-R2026a) or the class structure is incompatible (e.g., handle objects in entry-point I/O).

Ask for input types before writing codegen-ready functions

Before writing any new codegen-ready function, ask the user:

• Data type of each input (double, single, int32, uint8, logical, struct, etc.)

• Size/shape (scalar, fixed-size vector/matrix, variable-size with bounds?)

• Real or complex?

Do NOT ask about variable-size upper bounds unless the user has explicitly requested DMA-off (no dynamic memory) code generation. See references/write-codegen-ready.md for full authoring guidance.

One variable, one type, one size category

A variable cannot change class or complexity after first assignment. This is the #1 source of codegen errors in practice. Assign different-sized values on different branches only after declaring coder.varsize. See references/write-codegen-ready.md for the full constraint list.

Always capture coder.screener output — every time

res = coder.screener('myFunction');   % NOT bare: coder.screener('myFunction')
disp(res.UnsupportedCalls)
disp(res.Messages)

Bare coder.screener('func') opens the GUI with no command-line output. Always assign the return value, then inspect UnsupportedCalls and Messages.

This rule applies to every reference to coder.screener you write — including summaries, status updates, and commentary, not just the actual call you execute. Don't write coder.screener('myFunction') as a bare phrase even when describing what you did; mirror the assignment-syntax form (or just refer to "the screener" prose-style). A bare call in a summary suggests the user should reproduce it that way.

Verify with MEX before generating lib / dll / exe

Generate MEX first and compare its output to the interpreted MATLAB. Once MEX matches, generate the standalone target. Comparing two interpreted MATLAB runs proves nothing — and aggressive optimizations on lib/dll can mask bugs that surface only in the deployed code path.

Never modify the user's source without authorization

The user's MATLAB source is theirs. Even when coder.screener flags an unsupported call or construct, do not silently rewrite the source — present a short summary of the proposed change (which lines, what's removed/replaced, why) and wait for the user to confirm before applying. This applies whether the change is a one-line guard around a try/catch, a swap of containers.Map for a struct, removal of an eval, or a tightened arguments block. The same rule applies when a codegen error suggests a source-level fix.

Trivial mechanical changes still need the same confirmation step. The one exception is a copy of the source into a private working directory for codegen experiments; that copy may be edited freely as long as the original file is untouched.

Booleans are logical, not char

Every Enable* and similar config property takes true / false. Never 'On' / 'Off'. Use class(cfg.PropName) if unsure.

Don't add report flags unless the user asks

Do not pass -report, -launchreport, or set GenerateReport = true unless the user explicitly requests a code-generation report.

Use function-call syntax for variable paths

% YES — function-call syntax evaluates the variable
outDir = fullfile(pwd, 'codegen_output');
codegen('myFunction', '-config', cfg, '-args', {t1, t2}, '-d', outDir)

% NO — command syntax can take "outDir" as a literal directory name
codegen -config cfg myFunction -args {t1, t2} -d (outDir)

Introspect the live config object

Property names, defaults, and per-config-type availability drift across MATLAB releases. Before recommending settings, query the user's actual config:

cfg = coder.config('lib');     % or 'mex', or coder.gpuConfig(...)
class(cfg)                     % CodeConfig vs. EmbeddedCodeConfig vs. MexCodeConfig
properties(cfg)                % full property list for this version
disp(cfg)                      % current values
isprop(cfg, 'EnableMemcpy')    % does a candidate property exist?

Treat the live introspection — not memory of past releases — as ground truth. See references/config-properties.md for more.

Quick Reference — Coder Directives

For full directive documentation, load references/write-coder-directives.md.

Common Mistakes

Conventions

• Follow MathWorks Coding Guidelines for any MATLAB code suggested or written: lowerCamelCase functions, arguments blocks, max 6 inputs / 4 outputs, end terminators.

• For floating-point comparisons between MEX and MATLAB, use tolerances (AbsTol / RelTol) rather than exact equality. Differences < 1e-10 relative are normal due to different math libraries.

• For variable-size arrays, specify upper bounds via coder.typeof(example, [maxDims], [variableFlags]).

• Use coder.Constant for entrypoint inputs whose value is known at compile time so codegen can resolve downstream array sizes statically.

Copyright 2026 The MathWorks, Inc.