windows.h中的createevent与其他头文件中的冲突_crux（linkboy）与其他系统级编程语言对比...

一、IoT产业背景简介

据相关报告，预计到2025年，采用ARM / RISC-V等架构的芯片数量将增至一万亿颗，主要应用于智能家居、工业控制、自动驾驶汽车等领域。如何保证海量嵌入式设备软件系统的安全性、可靠性，对开发人员提出了越来越高的要求。本文主要从嵌入式软件体系安全可靠性这个维度，将crux(linkboy)与其他系统级编程语言，包括C语言、MicroPython、Rust作对比，展示物联网、边缘计算等场景下，编程语言的设计会对嵌入式软件系统的安全/可靠性产生哪些影响。

二、crux(linkboy)编程平台体系概述

linkboy早期的时候是一个编程语言/编译器，面向51、AVR嵌入式处理器；随着应用场景的扩展和完善，目前已形成一站式集成开发平台，包括前端的图形连线配置界面、图形模块库系统，中间层的仿真系统、RTOS、模块驱动程序库，以及后端面向51、AVR、ARM、RISC-V等处理器的指令集生成/运行环境。从4.0版本开始对各个组件进行了规范化命名，对应代号和版本如下：

1、crux 0.9：面向嵌入式应用的强类型静态编程语言(与C语言基本同构)

2、vos 2.0：一套嵌入式操作系统(runtime)，提供crux在各类处理器上的运行环境；

3、linkboy 4.0：基于crux和vos的图形化配置仿真界面，集成交互式开发平台；

三、各个编程语言对比：

(注：以上仅从安全相关的维度进行对比，可能会有疏漏和主观偏差)

四、crux面向嵌入式软件体系安全/可靠性介绍

编程语言的设计，对嵌入式软件的开发具有重要影响。crux定位是帮助工程师构建高安全性/高可靠性的嵌入式软件系统。本章节将从“规范化”、“安全运算体系”、“内置协程机制”、“多线程保护”这4个方向讲解crux语言针对系统安全的设计思路。

1. 规范化

crux在语法的设计上做了底层的重构，体现为更现代式的语言风格，例如局部变量可以在函数的任意位置定义，不限定必须在函数的开始；函数和全局变量等位置无关，支持先使用后定义(即完全摒弃了C语言的函数声明概念，也就不再需要用户给每个c文件维护一个h头文件)；移除了有争议的指针运算，用引用等价代替，在语言的使用上更清晰和简洁(引用类型的变量绑定目标后，其用法就和对应原生类型完全一样)。

2. 安全运算体系

变量类型和运算体系经过精心设计，通过“引用”功能性代替指针，避免了野指针导致的各类隐患；所有修改左值的运算不允许再返回值，防止意想不到的副作用；数据操作上，严格区分有符号数和无符号数，不允许混合运算，避免了常见的默认转换导致的数据溢出风险；透明化/跨平台的变量内存布局方案，隐藏大端小端的概念，工程师不需要担心字、双字是否对齐引起的移植性隐患。在使用crux编程时候，不用考虑底层CPU特性，不需关心是8位，16位，还是32位处理器，而是面对一个标准化的虚拟CPU。

3. 内置协程机制

使用协程是避免各类原子操作冲突的行之有效的方案。curx借鉴了谷歌的go语言，语言层面上对协程做了内置支持，自动处理协程函数的局部变量栈结构分配、函数调用管理。目前支持如下功能：协程的创建、并发执行、协程暂停、继续、强制终止、条件等待、安全沙箱等。由于语言/编译器集成对协程的支持和分析，可以最小化资源占用(每个协程仅需80字节)，对于8位AVR/arduino可以支持多达20个协程同时执行；32位GD32/STM32等芯片则可跑几百个协程。

经典应用场景：linkboy事件系统、多任务延时、网络通信并发、GUI人机界面交互…

未来探索应用：对接边缘AI框架，例如对摄像头识别出的大量视觉元素各分配一个协程并行处理；基于嵌入式数据库的接口进行传感器数据并行检索，等等。

现在的crux协程系统主要用于图形界面编程。以后会根据场景进行升级，通过增加功能和底层优化，使其能在越来越多的场合替代线程。并在不久的未来crux 1.0正式发布时，最终定型面向代码编程场景的语法体系。

四、多线程保护

尽管协程能替代很多线程的功能，但仍有一些情况必须要使用线程。线程是操作系统的概念，本文约定，嵌入式中断函数等也认为是一种特殊的线程。多线程对同一资源的使用可能导致系统错误，所以包括C语言在内的绝大多数编程语言都提供了volatile关键字和原子锁机制，确保安全。但这些语言有一个共同的缺点，就是不会在语言上强制程序员使用，一段临界代码，即使不加原子操作锁保护，或者一个多线程全局变量不加volatile关键字，编译器都不会报错，但这样的软件系统部署到产品上，却埋下了隐患。下面是软件故障导致汽车刹车失灵的一个案例：

汽车厂家称，一个软件错误可能会使电子稳定控制系统和防抱死制动系统失效，增加撞车的风险。

C语言假定开发人员是专家，它提供高自由度的同时也容易引入系统安全隐患；而我们希望一门语言能帮助更大众化的工程师群体，轻松开发高安全性软件系统。因此crux给出的解决方案是：直接移除volatile关键字，由语言本身负责做保护。或者用C语言的场景描述就是，编译器智能分析函数调用关系网，把可能会多线程访问的变量自动加上了volatile，因此这个关键字在crux里边已经没有意义了。这个自动分析工作是系统化的，除了volatile，它还负责检测所有可能的多线程资源访问冲突，并强制程序员在必要地方加上锁，不加锁则程序编译时就报错。这和Rust语言有相似的理念，即：一个crux程序只要能编译成功，就代表没有线程冲突错误(隐患)。下面通过一段场景代码做说明：

图中程序第9行不加lock锁的话，类似代码在C语言中也能编译通过，但是假如在极端情况下，驾驶员按下鸣笛按钮的一瞬间踩了刹车(通过CAN/modbus等总线向控制系统发出刹车信号)，这时候系统就出错了，鸣笛信号被误处理了两次(轻微事故级别)，但刹车信号直接被丢弃(严重事故级别)。而这个概率又可能很小，比如十万次才发生一次多线程冲突失误，产品测试阶段很难测出来。

同样的程序不加lock锁(下图第9行注释掉)，crux编译会报错，直接在源头上防止了安全隐患代码被部署到电子控制设备中：

以上程序仅是原理性演示，实际电控刹车系统远比这个程序复杂，但导致隐患的原因是相似的(线程冲突是其中一个重要因素)。除了刹车控制系统外，安全相关的场景还有很多，比如：消防预警/应急照明系统，电梯终端控制和总控，工业设备急停控制等。

(备注：名词volatile在网站服务器、电脑处理器等系统中主要指多级缓存数据同步/指令乱序重排，在嵌入式系统中一般是寄存器变量、IO地址。本文讨论的语境为嵌入式系统)。

五、crux未来远景图

目前在如下方向正在探索和开发中：

1、增加数组溢出/运算溢出异常处理系统；

2、为RISC-V指令集内核增加AOT/JIT编译，提高运行效率；

3、增量式编译；

4、增加准动态内存分配机制，由语言本身进行编译期内存分配和回收(参考Rust)

5、crux程序源源变换为C语言(在特殊情况下给用户提供回退到C语言的途径)；

6、提供windows/linux命令行编译工具；

7、其他方向调研

随着应用场景的深入研究和探索，crux语言也会不断发展和完善，目标是尽可能消除嵌入式 / 物联网等领域开发的各种软件安全隐患。借鉴开源开放协作模式，通过群策群力，把crux打造成为一门生态开放的，面向嵌入式构建安全可靠软件系统的编程语言。