albertovillaosorno/malbolge

# Malbolge Malbolge 是一个实验性的 C 转 Malbolge 编译器、执行系统、验证栈，以及围绕 1998 年 Malbolge 机器构建的可复现的编译器研究实验室。 面向人类的源语言是 C。生成的目标文件使用完整的 `.malbolge` 扩展名。其长期目标刻意设定得极不合理： 使普通的确定性 C 程序能够编译为 Malbolge，并以精确的语义执行，对翻译进行激进的优化，并最终将编译器本身编译为 Malbolge。 ## 项目状态 该仓库目前处于规范制定、研究设计和基础设施阶段。现有的内容包括：规范性的 1998 年机器规范、文档权威模型、研究方法论、法律边界、参考文献基线，以及 85 条已分类的 TODO 记录。生产级的 Rust VM、C VM、C 前端、编译器后端、优化器、JIT/AOT 引擎和加速器实现仍处于规划阶段。 [`TODO.md`](TODO.md) 仅包含未完成的工作。每个 TODO 标题在 [`docs/todo/open/`](docs/todo/) 下都有一条对应的分类记录。只有当 TODO 的契约、实现或研究结果、测试和证据达到持久化标准后，该 TODO 才会被移除。 ## 语义权威 成文的 1998 年 Malbolge 规范是经典机器的规范性定义。Ben Olmstead 的原始 C 解释器在 [`tools/malbolge/main.c`](tools/malbolge/main.c) 中保持原样，作为历史证据保留，而不是在它与规范相矛盾时作为语义权威。 这种区别是有意为之的。规范将 `<` 定义为输入，将 `/` 定义为输出，而历史解释器的实现则正好相反。规范还要求在遇到非图形化的可执行单元格时立即终止，而 C 实现则可能在不推进其指针的情况下陷入死循环。现代 VM、编译器、验证器、原生后端和加速器均遵循规范。未来一个明确命名为 `legacy-ben` 的模式将仅保留用于考古和差分诊断。 请参阅 `docs/technical/adr/` 下的规范权威 ADR（架构决策记录）、[规范机器规范][machine-spec]，以及 `docs/technical/specification/historical-undefined-behavior.md`。 ## 目标工作流 面向开发者的预期路径如下： ``` program.c | v tools/tidy | v c2malbolge | +--> deterministic C IR +--> ternary / guest-runtime IR +--> verified optimizer and block selection +--> address and self-modification layout | v program.malbolge | v Malbolge VM / native execution tiers ``` `tools/tidy` 计划作为一个树外的 clang-tidy 插件。它的核心契约比普通的代码检查更为严格： ``` tools/tidy accepts P => c2malbolge(P) succeeds for the declared target profile ``` 在通过“具备良好的可下推性（lowerability）”验证后，如果编译器拒绝编译，这属于工具缺陷，而不是用户的错误。 ## 工程模型 本仓库按职责进行组织，绝不按实现语言来划分。只要 Rust、C、C++、CUDA、Python、LaTeX 和 Malbolge 实现的是同一种功能，它们就可以并存在一起。Cargo 只是一种构建机制，而不是架构本身，本项目刻意避免将 Rust crate 变成人为的系统边界。 主要的职责层面包括： - `compiler/` 负责前端、IR、下推、布局、编码和源码映射； - `vm/` 负责精确的 Malbolge 状态机执行； - `execution/` 负责可选的解释器、AOT、JIT、去优化，以及原生的 x86-64/AArch64 执行层级； - `runtime/` 和 `libc/` 负责最终在 Malbolge 语义下执行的客户机设施，而不是作为宿主机的捷径； - `verifier/` 负责翻译验证、静态分析、差分检查、模糊测试、穷举检查和证明材料； - `accelerator/` 负责 CPU、CUDA、ROCm 及其他可替换的执行算力； - `optimizer/` 负责从已验证的研究中提升而来的优化职责； - `algorithms/` 负责可执行的研究算法，并在 `docs/research/algorithms/` 下保留对应的学术记录； - `interop/` 负责产品互操作性工程，例如可选的、由用户提供的 DOOM 实验； - `examples/` 负责项目自有的示例，以及一个仅用于追溯历史渊源的博物馆，该博物馆不会引入未经授权的第三方程序； - `tools/` 负责仓库工具，包括未经修改的历史解释器、客户机 C 代码验证，以及逆向工程/反编译工具。 空的或 speculative 的特定语言专属根目录并不代表架构。 ## 执行与性能 字面解释器仍然是受信任的兜底方案，但这并不是唯一计划中的执行策略。执行引擎可以将 Malbolge 解码为小型的内部执行 IR，简化已验证的状态图，在执行前编译稳定的区域，使用保护机制对频繁变化的热点区域进行特化，并在假设失败时安全地去优化回解释器执行。 原生执行层是可选的。计划提供的控制项包括 `--no-jit`、`--no-aot` 和 `--interpreter-only`，以便基准测试可以在纯 Malbolge 执行、仅 AOT、仅 JIT 和全分层执行之间进行比较，而不会隐式重用原生代码。 加速器硬件和搜索算法是独立的移植项目。CUDA 是第一个 GPU 适配器，而不是一种语义依赖。相同的随机、枚举、学习、混合或未来的搜索算法应该能在 CPU、CUDA、AMD 或其他后端上运行（只要可行）。资源调度旨在适应可用的机器，而不是假设一个固定的 VRAM 预算。 ## 验证模型 庞大的启发式组件不会仅仅因为运行速度快就获得信任。随机搜索、CUDA 内核、学习到的指导模型、状态图优化和布局求解器可以提出候选方案；而小型的确定性验证将决定是否采纳该候选方案。 因此，本仓库将以下内容分离开来： ``` proposal / search / optimization | v independent verifier | v accepted artifact ``` 现代的 Rust VM、独立的 C VM、有界穷举检查、数学契约，以及在文档记录的一致性子集上的历史解释器，提供了相互重叠的证据，而不是一个单一的庞大权威预言机。 ## 编译器研究实验室 Malbolge 刻意呈现出极高的难度，这使得编译器算法很容易受到压力测试。本仓库将这种困难性作为一种研究工具，而不是作为掩盖基准测试不透明性的借口。 真正的研究算法使用语义镜像： ``` docs/research/algorithms// algorithms// ``` 文档部分记录了问题、假设、先前的工作、数学模型、实验设计、证据、局限性和结论。可执行部分包含了实现、验证器边界、实验清单、测试，以及一个被 Git 忽略的本地 `out/` 目录。 普通的工程算法不会被强行包装成虚假的论文。可重用的生成器基础设施和应用程序套件可以与研究实现共享 `algorithms/` 目录，同时明确表明它们处于学术镜像之外。 例如，`algorithms/diff/` 是通用的生成基础设施，而 `algorithms/doom/` 是 DOOM 应用程序套件。 研究比较使用可扩展的参数化挑战家族和多目标证据，而不是单一的神奇分数。预期的产出是容量曲线和在各项指标（如获得已验证解的时间、生成代码的大小、运行时指令数、峰值 RAM/VRAM、验证器成本、随机成功概率以及最大解决难度）上的帕累托前沿。 机器可读的挑战也正在规划中，以便 LLM 或编译器代理可以在不成为正确性权威的情况下提出算法或优化遍： ``` agent proposes | v repository verifier | v benchmark arena | v reproducible evidence ``` ## 研究规范 一段华丽的文字并不等于证据。仓库的研究旨在让来源轨迹变得可检查：哪项主张来自于哪个来源，哪些是直接验证过的，哪些仍是次要的或尚未解决的，哪些来源相互矛盾，矛盾是如何解决的，以及哪些证据被废弃了。 这种方法改编自作者 Ameyalli 研究仓库中使用的来源追溯规范。Malbolge 保留了适合软件项目的结构：规范的外部来源记录位于 `docs/bibliography/`，研究结论位于 `docs/research/`，技术行为位于 `docs/technical/`，法律分析位于 `docs/legal/`。 请参阅 `docs/bibliography/provenance-and-methodology/repository/` 下的来源验证账本以及 [科学方法契约][scientific-method]。 ## 真实世界的压力测试 DOOM 是一个可选的互操作性和性能演示，而不是科学基准测试的权威。用户可以将合法的源码检出放置在被忽略的 `doom/` 输入目录中。计划中的工具随后将生成： ``` user DOOM source | v quality recipe + source-bound diff | v algorithms/doom/quality/out/doom_fixed/ | v optional amalgamation recipe + source-bound diff | v algorithms/doom/amalgamate/out/doom_amalgamated.c | v c2malbolge | v doom.malbolge ``` 本仓库不分发 DOOM 源码或游戏数据。生成的工件保留其输入项应遵守的任何上游义务。DOOM 的存在是为了证明该流水线能够在一个庞大、老旧且难以处理的实际 C 代码库中存活下来；而参数化基准测试竞技场的存在是为了科学地区分算法的优劣。 ## 自举 长期的符合性目标是：

标签：Malbolge, Vectored Exception Handling, 代码优化, 可视化界面, 底层开发, 形式化验证, 生成式AI安全, 编译器, 虚拟机, 逆向工具, 通知系统