告别 matiec 与 DockeraiDgePLC Editor 全面拥抱 STVM 字节码编译项目地址https://gitee.com/galaxy_0/ai-dge-plceditor.git一、背景传统编译链的阿喀琉斯之踵aiDgePLC Editor 是一款面向 aiDgeController Runtime 的集成开发环境支持以结构化文本STIEC 61131-3编写 PLC 程序。在早期版本中编辑器采用的是工业界经典的matieciec2c Docker 交叉编译工具链PLC 项目 JSON → plc.xml → program.st ──[matiec/iec2c]──▶ C 源码 ──[gcc Docker]──▶ 固件这条链路为项目立下了汗马功劳但也暴露出三个难以回避的痛点环境依赖沉重用户必须安装 Docker 并拉取数十 MB 的交叉编译镜像首次编译启动慢、网络受限场景几乎不可用。部署与跨平台复杂matiec 与 gcc 的不同架构二进制需要逐一维护每支持一块新板卡就要维护一套交叉编译工具链。编译反馈冗长ST → C → 汇编 → 目标码的多层转换使调试信息与源码的对应关系变得模糊。二、新选择STVM —— 为 ST 而生的字节码虚拟机STVMStructured Text Virtual Machine是一款轻量级的 ST 字节码虚拟机提供完整的编译与运行时工具链工具作用stvmc将 ST/IEC 源码编译为.bytecode字节码stvm-run在主机或嵌入式设备上加载并执行字节码stvm-disasm字节码反汇编辅助调试stvmc支持两套语法前端旧版 ST 子集.st与完整的IEC 61131-3模式.iec/--iec后者覆盖 FUNCTION、FUNCTION_BLOCK、CONFIGURATION、RESOURCE、TASK 等完整构造恰好匹配 xml2st 生成的 OpenPLC 标准 ST 结构。三、为什么是 STVM我们选择 STVM 而非其他方案基于以下考量“一次编译到处运行”字节码与目标硬件解耦运行时只需一个 stvm 解释器省去 Docker 与交叉编译器。编译即交付program.st → program.bytecode一步到位产物可直接上传至 Runtime编译速度快、日志直接对应源码行号。静态单文件部署我们将stvmc.exe以/MT静态运行时构建仅依赖KERNEL32.dll无需额外运行库随编辑器一同分发。开源协议友好STVM 采用 GPL-2.0 双授权与 aiDgePLC EditorGPL-3.0的开源路线一致。四、适配历程本次适配不是简单的换个编译器而是对编译流水线的一次重构。1. 工具链替换program.st ──[stvmc --iec]──▶ program.bytecode新增StvmCompilerModule封装stvmc调用checkAvailability()探测可用性compileToBytecode()生成字节码。强制使用--iec模式xml2st 产出的program.st虽为.st扩展名但包含 IEC 完整构造旧 ST 子集无法解析。输出路径沿用原有src/program.bytecode便于 v4 Runtime 打包上传。2. 清理 C 时代遗产字节码流程不再产出 C 文件以下步骤被整体移除handleGenerateDebugFilesxml2st--generate-debug生成 C 调试文件handleGenerateGlueVars生成LOCATED_VARIABLES.hC/C 块头文件与代码生成c_blocks.h/c_blocks_code.cppstCC 桥接代码注入Docker 交叉编译compiler-cross-module保留了仍有价值的环节JSON→XML、XML→ST、静态资源拷贝、MD5 提取、运行时配置生成与上传。3. 上游协作适配过程中我们向 STVM 提交了一处关键修复IecParser.cpp的parseTaskDeclaration()原先不消费 TASK 声明末尾的分号导致 OpenPLC 标准的TASK task0(...);解析失败。修复后 TASK 声明可被正确接受。五、编译流水线现状项目 JSON │ ▼ handleGenerateXMLfromJSON plc.xml │ ▼ handleTranspileXMLtoST (xml2st) program.st │ ▼ handleCompileSTtoBytecode (stvmc --iec) program.bytecode │ ├─ OpenPLC Runtime v3 ──► 上传 program.st / program.bytecode └─ OpenPLC Runtime v4 ──► 打包 src含 bytecode 配置上传六、用户体验提升零 Docker 依赖下载即用不再需要配置容器环境。编译速度显著提升省去 C 编译与链接ST 到字节码通常在毫秒到秒级完成。错误定位精准stvmc的类型检查直接报告源码行号例如line 6: undefined variable b。配置页面精简移除了 Cross Compiler、Device、Communication Port 等面向旧工具链的选择项界面更聚焦于程序本身。七、已知边界与后续规划STVM 的 IEC 前端仍在快速演进中当前存在少量已知限制例如 RESOURCE 内的 VAR_GLOBAL 段、表达式中直接使用%IX0.0地址字面量我们正与上游保持沟通并持续跟进。同时团队正推进stvm 嵌入式运行时在 aiDgeController 硬件端集成 stvm-run实现字节码直接执行。调试符号增强让 stvmc 输出的字节码携带更丰富的源码映射信息支持在线调试。构建流程沉淀将 stvm 的获取、补丁、静态构建流程固化为一键脚本确保版本升级可复现。八、结语从 matiec 的 C 代码生成到 STVM 的字节码编译aiDgePLC Editor 完成了一次编译哲学的升级不再把 ST 翻译成 C 再交给通用编译器而是让 ST 直接成为可执行的字节码。这不仅简化了部署、加快了反馈也为后续在嵌入式端实现真正的解释执行与热更新打开了大门。如果你也在为 PLC 编程环境的编译链路过重而烦恼欢迎关注 aiDgePLC Editor 与 STVM 的后续进展一起让 ST 编程更轻、更快、更现代。
告别 matiec 与 Docker：aiDgePLC Editor 全面拥抱 STVM 字节码编译
告别 matiec 与 DockeraiDgePLC Editor 全面拥抱 STVM 字节码编译项目地址https://gitee.com/galaxy_0/ai-dge-plceditor.git一、背景传统编译链的阿喀琉斯之踵aiDgePLC Editor 是一款面向 aiDgeController Runtime 的集成开发环境支持以结构化文本STIEC 61131-3编写 PLC 程序。在早期版本中编辑器采用的是工业界经典的matieciec2c Docker 交叉编译工具链PLC 项目 JSON → plc.xml → program.st ──[matiec/iec2c]──▶ C 源码 ──[gcc Docker]──▶ 固件这条链路为项目立下了汗马功劳但也暴露出三个难以回避的痛点环境依赖沉重用户必须安装 Docker 并拉取数十 MB 的交叉编译镜像首次编译启动慢、网络受限场景几乎不可用。部署与跨平台复杂matiec 与 gcc 的不同架构二进制需要逐一维护每支持一块新板卡就要维护一套交叉编译工具链。编译反馈冗长ST → C → 汇编 → 目标码的多层转换使调试信息与源码的对应关系变得模糊。二、新选择STVM —— 为 ST 而生的字节码虚拟机STVMStructured Text Virtual Machine是一款轻量级的 ST 字节码虚拟机提供完整的编译与运行时工具链工具作用stvmc将 ST/IEC 源码编译为.bytecode字节码stvm-run在主机或嵌入式设备上加载并执行字节码stvm-disasm字节码反汇编辅助调试stvmc支持两套语法前端旧版 ST 子集.st与完整的IEC 61131-3模式.iec/--iec后者覆盖 FUNCTION、FUNCTION_BLOCK、CONFIGURATION、RESOURCE、TASK 等完整构造恰好匹配 xml2st 生成的 OpenPLC 标准 ST 结构。三、为什么是 STVM我们选择 STVM 而非其他方案基于以下考量“一次编译到处运行”字节码与目标硬件解耦运行时只需一个 stvm 解释器省去 Docker 与交叉编译器。编译即交付program.st → program.bytecode一步到位产物可直接上传至 Runtime编译速度快、日志直接对应源码行号。静态单文件部署我们将stvmc.exe以/MT静态运行时构建仅依赖KERNEL32.dll无需额外运行库随编辑器一同分发。开源协议友好STVM 采用 GPL-2.0 双授权与 aiDgePLC EditorGPL-3.0的开源路线一致。四、适配历程本次适配不是简单的换个编译器而是对编译流水线的一次重构。1. 工具链替换program.st ──[stvmc --iec]──▶ program.bytecode新增StvmCompilerModule封装stvmc调用checkAvailability()探测可用性compileToBytecode()生成字节码。强制使用--iec模式xml2st 产出的program.st虽为.st扩展名但包含 IEC 完整构造旧 ST 子集无法解析。输出路径沿用原有src/program.bytecode便于 v4 Runtime 打包上传。2. 清理 C 时代遗产字节码流程不再产出 C 文件以下步骤被整体移除handleGenerateDebugFilesxml2st--generate-debug生成 C 调试文件handleGenerateGlueVars生成LOCATED_VARIABLES.hC/C 块头文件与代码生成c_blocks.h/c_blocks_code.cppstCC 桥接代码注入Docker 交叉编译compiler-cross-module保留了仍有价值的环节JSON→XML、XML→ST、静态资源拷贝、MD5 提取、运行时配置生成与上传。3. 上游协作适配过程中我们向 STVM 提交了一处关键修复IecParser.cpp的parseTaskDeclaration()原先不消费 TASK 声明末尾的分号导致 OpenPLC 标准的TASK task0(...);解析失败。修复后 TASK 声明可被正确接受。五、编译流水线现状项目 JSON │ ▼ handleGenerateXMLfromJSON plc.xml │ ▼ handleTranspileXMLtoST (xml2st) program.st │ ▼ handleCompileSTtoBytecode (stvmc --iec) program.bytecode │ ├─ OpenPLC Runtime v3 ──► 上传 program.st / program.bytecode └─ OpenPLC Runtime v4 ──► 打包 src含 bytecode 配置上传六、用户体验提升零 Docker 依赖下载即用不再需要配置容器环境。编译速度显著提升省去 C 编译与链接ST 到字节码通常在毫秒到秒级完成。错误定位精准stvmc的类型检查直接报告源码行号例如line 6: undefined variable b。配置页面精简移除了 Cross Compiler、Device、Communication Port 等面向旧工具链的选择项界面更聚焦于程序本身。七、已知边界与后续规划STVM 的 IEC 前端仍在快速演进中当前存在少量已知限制例如 RESOURCE 内的 VAR_GLOBAL 段、表达式中直接使用%IX0.0地址字面量我们正与上游保持沟通并持续跟进。同时团队正推进stvm 嵌入式运行时在 aiDgeController 硬件端集成 stvm-run实现字节码直接执行。调试符号增强让 stvmc 输出的字节码携带更丰富的源码映射信息支持在线调试。构建流程沉淀将 stvm 的获取、补丁、静态构建流程固化为一键脚本确保版本升级可复现。八、结语从 matiec 的 C 代码生成到 STVM 的字节码编译aiDgePLC Editor 完成了一次编译哲学的升级不再把 ST 翻译成 C 再交给通用编译器而是让 ST 直接成为可执行的字节码。这不仅简化了部署、加快了反馈也为后续在嵌入式端实现真正的解释执行与热更新打开了大门。如果你也在为 PLC 编程环境的编译链路过重而烦恼欢迎关注 aiDgePLC Editor 与 STVM 的后续进展一起让 ST 编程更轻、更快、更现代。
