TermiNexus
2ba38ae842
现象：同一条命令的编译时间在 ~400s 与 ~1180s 两档之间随机跳（PROF 目录当日 366s~2239s），用户反馈"耗时不降反增"。 根因（三份 profile 实证）： - 旧 _PickWorkerCount 用 `by_mem = max(1, avail_mb // per_worker_mb)` 按**可用** 物理内存夹 worker 数：可用稍紧（<~2.8GB）就整体降为 1 ⇒ **静默退回串行**。 其文档字符串自己就写着"76 文件逐个翻译 1180s，并行时 ~400s，波动 2-3 倍"。 - PROF/20260930_224857（438.40s）：主进程 _translate_file **0 次**、 StructGen/HandlesImports/HandlesClassDef **0 条记录**、总调用 7.28 亿 ⇒ 翻译在 worker 进程里做完了（未 profile），主进程只在等 → **并行档**。 - PROF/20260930_231916（1048.55s）与 20260930_235354（1168.15s）： _translate_file **75 次全在主进程**、_parallel_translate_worker/_batch 0 次、 总调用 19.6 亿 ⇒ **串行档**（1180s 档）。 ⇒ 拿 438s 当基线比 1168s 是"并行 vs 串行"。本次 A/B（同为串行、总调用 19.616 亿 vs 19.631 亿）里各项优化均为正收益（_RewritePlain −5.0s、 __exit__ −1.5s、re.match+_compile −1.3s、_RewriteQuoted −0.75s…）； +12% 属机器波动（同一批 C 函数在调用次数不变下变慢 25%~73%）。 改动（口径由用户定：不降级 + 预分配内存避免波动 + 强制要求预留内存）： 1. **不降级**：删掉"内存紧就退串行"。worker 数 = min(cpu_count, n_files)， 不再因可用内存抖动而变化。 2. **预分配校验 + 强制预留**：新增 _MemStatus()（读可用/总量）与 _ProbeReserveMb()——按 base×per_worker_mb（翻译 350 / 编译 400）分块**真正 提交**该预算（峰值=预算），成功后立即整体释放，紧接其后创建 worker 进程 由 OS 复用这批页。等于先向 OS 确认"这笔预算确实拿得到"，而不是只看含大量 可回收页的 ullAvailPhys。 3. **fail-fast**：可用内存 < 预算、或预分配校验提交失败 ⇒ RuntimeError 报出 "需要 X MB（N worker × M MB）/ 当前可用 Y MB / 总量 Z MB"，由使用者释放内存 或**显式** TPC_JOBS=N 重跑（N=1 即显式接受串行）。不再静默降级。 4. 新增 TPC_JOBS=N 显式覆盖（跳过校验，使用者自担内存风险）。 5. 每次决策都打日志：显式指定 / 读不到内存状态 / 预分配校验耗时 / 最终 workers。 已知取舍：内存确实不足时编译会**直接失败**（这是"不降级"的应有语义），出路是 释放内存或 TPC_JOBS=N；预分配校验会短暂占用峰值=预算的内存（约 1GB/秒级耗时）。 未动（下一步候选）：串行档的真热点 StructGen._generate_structs（151s 自身 / 480s 累计，被调 36,389 次≈每类 22 次，O(类数²)）。
TransPyC
TransPyC 是一种基于 Python 语法的系统级编程语言编译器，将 Python 子集（通过 t/c 模块类型注解赋予 LLVM 语义）编译为原生机器码。它不是 Python 的子集，也不是 C 的语法糖——它拥有独立的类型系统、两阶段编译模型和 SHA1 命名空间机制，适用于操作系统内核、嵌入式系统、驱动程序等底层开发场景。
能力证明
TransPyC 已用自身实现以下组件，证明其作为系统级语言的成熟度：
- ViperOS —— 真实操作系统内核（ViperOS/），含 gdt/idt/isr/mm/sched，可在 QEMU 启动
- 自研 Python 解析器 —— includes/ast/（4,176 LOC），用 TransPyC 自己写的词法+语法+AST，覆盖 CPython 几乎全部语法
- 自研 LLVM IR 生成库 —— includes/llvmlite/（~1,500 LOC），用 TransPyC 自己写的 IR 文本生成器，18/18 测试通过
- zlib 移植 —— Test/ZlibTest/，完整 deflate/inflate/huffman/checksum（~1,900 LOC）
- Win32 FFI 绑定 —— includes/w32/，file/memory/process/sync/console 全覆盖
- 泛型容器 —— includes/linkedlist.vp，
@t.NoVTable+ PEP 695 递归泛型继承class GNode(GSListNode[GNode])
核心设计理念
- Python 语法，LLVM 语义：源文件是合法的 Python 语法，但通过
t模块类型注解赋予 LLVM 级别的语义 - 类型注解即编译指令：类型注解决定 LLVM IR 的生成，不是可选的提示
- 两阶段编译：先提取声明接口（
.vpi+.stub.ll），再翻译源文件为含代码的.ll - SHA1 命名空间：每个源文件按内容 SHA1 哈希命名，自动消除跨模块符号冲突
- 零运行时开销：编译为原生代码，无 GC、无解释器、无虚拟机
自举进展
TransPyC 正在追求完全自举——用 TransPyC 重写 TransPyC 编译器自身。当前状态：
- ✅ 前端：
includes/ast/已替代 Pythonast模块依赖 - ✅ 后端：
includes/llvmlite/已替代 Pythonllvmlite依赖 - ⏳ 中间层：
lib/core（~20K LOC）待用 TransPyC 重写
模块总览
Viper 语言通过两个核心模块提供类型和操作支持：
| 模块 | 用途 | 导入方式 |
|---|---|---|
t |
类型定义系统 | import t |
c |
C 语言操作指令 | import c |
快速上手
- 环境：Python 3.12+、LLVM（llc/clang）、Windows（当前主平台）
- 构建项目：在项目目录运行
python ../Projectrans.py build（详见 wiki/12-project.md） - 示例：参考 Test/ 下 30+ 测试项目（AstTest/ZlibTest/NoVTableTest/LLvmLiteTest 等）
- 写第一个程序：
import t, c
from stdint import *
import stdio
def main() -> CInt | CExport:
stdio.printf("Hello, Viper!\n")
return 0
文档索引
| 文件 | 内容 |
|---|---|
| 01-overview.md | 语言概述、两阶段编译流程、SHA1 命名空间、t.CDefine/t.CExport/t.CInline 深度解析 |
| 02-type-system.md | 类型系统（基本类型、指针、数组、结构体、联合体、枚举、typedef、__attribute__） |
| 03-variables.md | 变量声明与赋值（含 t.CDefine 常量） |
| 04-functions.md | 函数定义与调用（含 t.CExport、t.CInline、t.CDefine 函数、-> tuple[...] 多返回值） |
| 05-classes.md | 类与数据布局（结构体、联合体、枚举、typedef、位域） |
| 06-oop.md | 面向对象与运算符重载（@t.Object、@t.CVTable、@t.NoVTable、继承、dunder 方法） |
| 07-control-flow.md | 控制流（条件、循环、match） |
| 08-c-operations.md | C 语言操作（指针、内联汇编、FFI 外部函数声明、LLVM IR 内联） |
| 09-exceptions.md | 异常处理 |
| 10-imports.md | 模块与导入系统（存根生成、SHA1 命名空间与导入） |
| 11-builtins.md | 内置函数与运算符 |
| 12-project.md | 项目配置与构建（增量编译、SHA1 映射） |
| 13-bootstrapping.md | 自举可行性分析（当前进展、剩余工作、路径规划） |