matlab-generate-code

name	matlab-generate-code
description	Generate, verify, refine, and accelerate C/C++ or CUDA code from MATLAB with MATLAB Coder, Embedded Coder, GPU Coder, or MATLAB Test. Also covers writing codegen-ready MATLAB code: language constraints, coder.* directives, and optimization patterns. Triggers on: codegen, MEX, deploy MATLAB as C/C++, GPU Coder, coder.screener, coder.config, coder.gpuConfig, coder.typeof, coder.runTest, matlabtest.coder.TestCase, SIL, embedded config, no dynamic memory, EnableMexProfiling, coder.timeit, coder.perfCompare, %#codegen, writing codegen-ready MATLAB, code generation readiness, coder.varsize, coder.unroll, coder.noImplicitExpansionInFunction, coder.ceval, coder.inline, coder.extrinsic, coder.const, coder.classSignature, class codegen limitations, temporal types codegen, DMA-off, stack-only, host-target InstructionSetExtensions, SIMDAcceleration, OptimizeReductions, host SIMD tuning, host OpenMP, codegen performance.
license	https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md
metadata	{"author":"MathWorks","version":"1.1"}

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, coverage, CI/CD, App Designer) → use matlab-write-test. 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.

User intent	Load
Writing new codegen-compatible MATLAB; reviewing MATLAB for codegen readiness; fixing codegen errors; %#codegen; language constraints; type/size rules	references/write-codegen-ready.md
Understanding a specific coder.* directive (coder.varsize, coder.const, coder.inline, coder.unroll, coder.extrinsic, etc.)	references/write-coder-directives.md
Using MATLAB classes in codegen; class limitations; coder.classSignature; handle vs value class restrictions	references/write-class-limitations.md
Generate C/C++/CUDA code (MEX, lib, dll, exe), specify input types, fix coder.screener issues	references/generate-code.md
Verify generated code matches MATLAB; write coder.runTest / matlabtest.coder.TestCase tests; SIL setup	references/verify-code.md
Tune a working config for a deployment goal (embedded / speed / readability / size / safety); SIMD values (SIMDAcceleration, InstructionSetExtensions), OpenMP, OptimizeReductions	references/refine-config.md
Profile generated MEX, measure coder.timeit / coder.perfCompare, find hotspots	references/accelerate-mex.md
Look up a config property's name, availability, or non-obvious behavior	references/config-properties.md

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

Directive	Purpose	Key gotcha	Available From
%#codegen	Enable codegen analysis	Must be on/after function signature	R2011a
coder.typeof(val, sz, varDims)	Define input type+size for codegen call	varDims is logical array — true = variable	R2011a
coder.varsize('x', [bounds])	Declare variable-size with upper bounds	Without bounds → requires DMA; declare before first assignment	R2011a
coder.const(expr)	Evaluate expr at compile time	Expression can be arithmetic, a function call, or a combination	R2013b
coder.extrinsic('fn')	Exclude function from compilation	No-op in lib/dll/exe unless paired with coder.const	R2011a
coder.inline('always'|'never')	Control function inlining	Use 'always' for small hot helpers	R2011a
coder.unroll(range)	Unroll loop at compile time	Required for heterogeneous cell / varargin iteration	R2011a
coder.noImplicitExpansionInFunction	Disable broadcasting overhead	Only when operands always match in size	R2021b
coder.target('MATLAB')	Branch between MATLAB and codegen paths	Inactive branch is eliminated from generated code	R2011a
coder.nullcopy(zeros(m,n))	Allocate without zeroing	Only safe if every element is written before read	R2011a
coder.ClassSignature	Direct class code generation entry point	Requires enableCodegenForEntryPointClasses once per session	R2026a

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

Common Mistakes

Mistake	Correct Approach
coder.screener('func') without capturing return value	res = coder.screener('func') then inspect res.UnsupportedCalls and res.Messages
Jumping straight to lib / dll without MEX verification	Generate MEX first, compare outputs to MATLAB, then generate the final target
EnableRecursion (does not exist)	EnableRuntimeRecursion
DynamicMemoryAllocation = 'Off'	EnableDynamicMemoryAllocation = false (logical, not char)
MemcpyThreshold = 0 to disable memcpy	EnableMemcpy = false
Comparing two interpreted MATLAB runs to "verify" generated code	Use coder.runTest (MEX replacement) or matlabtest.coder.TestCase; or SIL with Embedded Coder
coder.timeit(@myFunction, ...) (function handle)	coder.timeit('myFunction', numOutputs, {args}) — string name
Profiling the interpreted MATLAB function instead of the MEX	Profile myFunction_mex; interpreted MATLAB has different performance characteristics
Test script run under coder.runTest without assert statements	Always include assertions — coder.runTest produces no output on success otherwise
Building MEX in every test method with identical input types	Build once in TestClassSetup; rebuild per test only when input type specs differ
Calling the MATLAB function manually in matlabtest.coder.TestCase tests	verifyExecutionMatchesMATLAB calls MATLAB internally — just execute then verify
Command-syntax -d (outDir) for output directory	Function-call syntax: codegen('func', '-config', cfg, '-args', types, '-d', outDir)
Adding -report, -launchreport, or

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.

---