企业官网建设流程全解析

• 示例工程

本文以 Bitwise 项目的发布公告（README.md）为主线，完整梳理这个"从零构建计算机"教学项目的缘起、交付形式、参与门槛与六个月路线图，并结合仓库中已经落地的 Ion 编译器、RISC-V 工具链、Rattle HDL 等源码，验证路线图上的哪些环节已经走出了第一步。读完后，你将清楚 Bitwise 的设计哲学与整体技术路线，并能定位到仓库中对应的实现文件继续深入研究。

一、项目缘起：为什么"从零构建"

README 开篇引用了费曼的黑板名言：

"What I cannot create, I do not understand"（凡我不能创造的，我就没有真正理解它。）

项目发起人是 Per Vognsen，拥有 15 年以上游戏开发与系统编程经验，曾任职于 Epic Games、NVIDIA、RAD Game Tools，最近一家是 Oculus。他在 2017 年决定从职业编程中抽身，用几年时间完成一个长期梦想：通过示例（by example）展示如何从零构建系统，并聚焦低层计算（low-level computing）。

项目核心主张可以归纳为三点：

1. 简单性优先：README 明确指出，只要我们强烈地偏向简单性、而不是在功能完整性或性能上追求边际收益，这些东西（编译器、内核、硬件设计等）可以比大多数人想象的"更简单、更快速"地完成。
2. 不竞争：目标不是压倒或竞争任何现有产品（not to outdo or compete with any existing product），而是用真实的硬件和软件展示"事情是如何运作的"。
3. 全免费、公有领域：项目产出包括教学视频、文章和软硬件源码，全部免费；代码进入公有领域（public domain），人人可研究、可扩展；作者以个人储蓄支持项目，不要求也不接受资金捐助（见 FAQ.md 与 LICENSE.md）。

参与门槛：几乎不需要专用硬件

尽管项目以硬件为重点，README 特别强调：参与 Bitwise 几乎不需要任何特殊硬件或 FPGA 开发板。所有开发都使用免费工具，运行在普通的 Windows、Linux 或 Mac 电脑上；FPGA 板主要用于调试目的，而且项目刻意最小化在真实硬件上花费的时间，因为相比仿真（simulation），真机调试往往更痛苦、更耗时。FAQ.md 进一步解释：团队会为主外设（如 DDR3 DRAM 和其他 IO 接口）创建模拟器和周期精确（cycle-accurate）模型；即便你拥有 FPGA 板，开发过程中也不会经常直接使用。如果坚持上真机，目标是一块约 100 美元入门级板和一块约 400 美元的高阶板，但"这不是必须的"。

二、你将学会构建什么

README 列出了六类"你将学会构建"的东西，这是整个项目的能力清单：

值得注意的一条线索是：上表中的"系统应用"列在仓库中已经是最成熟的模块。这正对应 README 路线图中"第一个大项目是类 C 系统语言编译器"的规划——编译器先于一切其他软件存在，因为后续所有工具都用它来写。

三、设计哲学：简单是刻意选择，而非妥协

README 反复传达同一个价值观：

• "strongly favor simplicity over marginal gains in feature completeness or performance"——在简单性与功能/性能边际收益之间，坚定选择前者；
• "The goal is not to outdo or compete with any existing product; the goal is to show how things work with real hardware and software"——目标是教学，不是造出最强方案。

notes/ion_motivation.md（项目对首个核心语言的设计备忘录）把这一哲学具体化成了目标与非目标。目标包括：易于实现、对 C 程序员零学习曲线、减少不必要的特性、可用于宿主机（Windows/Linux/Mac x86/x64）与目标机（RISC-V）双重开发；非目标则明确排除"史上最佳语言综合征"、过度抬升抽象层级、内存/整数溢出安全等。它选择了 C 的类型系统与机器模型，但用"简单、LL(1)、不依赖符号表"的语法替换 C 的解析难题，宿主端输出等价的惯用 C 代码、目标端直接输出机器码。这解释了为什么 Bitwise 的语言与工具链可以保持轻量——它是教学优先的刻意取舍，而不是能力不足。

FAQ.md 中还提到项目的重要思想来源是 Niklaus Wirth 的 Oberon 系统及其工作整体，这与路线图中"从 RV32I 小核做起、逐步增强"的渐进式硬件路线一脉相承。

四、项目结构与参与方式

README 的 Structure 一节描述了项目的运作节奏（原文注明"高度取决于社区反馈，可能变化"）：

• 全时投入：作者计划把 Bitwise 当作持续数年的全职投入，避免倦怠（avoiding burnout）是主要优先事项。
• 直播：计划每日或隔日在 Twitch 直播，每场一至两小时；视频稍后发布到 YouTube。notes/streams.md 的 Day 4 记录显示，由于"追看视频内容太吃力"的社区反馈，节奏随后调整为**半日播（周一/周三/周五）**外加随机加播。
• 博客：每周或隔周发布博文，总结自上次更新以来的进展。
• 代码评审保证不漏行：每次直播以代码评审开场，逐一审视自上次直播以来提交的所有 diff，"即使大量代码必然是在直播外写成的，你也不会错过任何一行代码"；评审结束后把最新变更推送到 GitHub 仓库。
• 多轨道交替：为了保持趣味，直播频繁在不同开发轨道间切换——某一周可能在主软件任务与主硬件任务之间交替，也常有随机副题；大多数直播是现场编码（live coding），少数采用常规演示形式。
• 独立文章：在周更总结之外，作者会把直播内容提炼成独立文章。文章受众比直播观众大得多，能帮助新观众或中断的观众快速追平进度——毕竟对大多数人来说，靠看直播回放追进度并不现实。

前置要求

• 硬性要求只有 C 语言熟练（fluent C programmers）。Python 是次要语言，但事先会 Python 不是前置条件。
• 节奏很快：作者会给出许多主题概览，但不可能面面俱到，因此会尽可能附上延伸阅读的指引。
• FAQ.md 补充：还需要计算机本科阶段通常会学到的算法与数据结构等基础概念；"正式前置条件很少，但不要期待它容易"。

配套开发环境（来自 FAQ）

每周时间投入

FAQ 给出两种极端：只关心项目动态的轻度参与只需每周约一小时（读博客、偶尔看视频）；把它当高强度大学课程则每天需要数小时（看直播、研究代码、自己写代码）。项目采用分段式设计与构建：你可以在任何自然停驻点退出，带走一段自包含的新知识；目标让每隔几周出现一个自然里程碑。反过来，如果中途加入，过往的总结与文章可以帮你快速追平。所有材料在项目结束后也将长期免费可用。

排期

• 预期直播时间：周一至周五，6 PM PDT / 9 PM EDT / 2 AM CET。
• 开播（kick-off）直播原定 3 月 12 日，以概览和问答为主（notes/streams.md 记录 Day 0 为 2018 年 3 月 12 日）。
• 第一个大项目是类 C 系统语言编译器，预计数周完成，之后同步启动硬件轨。
• 作者当时位于泰国，该时刻表是其在各时区间的折中；每年 8 月会在欧洲待一个月，届时时刻表会强制轮换，也可能把部分直播挪到周六/周日早午场照顾欧洲观众。

五、六个月路线图

README 的 Roadmap 一节（原文注明"可能变化，但能说明计划方向"）对应约六个月的预估工作量，同时推进软件与硬件两条轨道。

硬件轨

1. 先学数字逻辑：学习如何用 HDL 设计硬件；而且将设计一门自研 HDL 及其配套工具链，包括软件实现的模拟器和调试工具。
2. 小型练手项目：沿路会做许多有趣的迷你项目，例如"纯用逻辑门设计一个 Pong"，以及实现 Zachtronics 游戏 TIS-100 中玩具并行计算机的变体。
3. 从零设计可综合到真实 FPGA 的计算机：包括 RISC-V CPU、GPU，以及 DDR3 内存、HDMI 音视频、以太网等 IO 接口控制器。

软件轨

1. 一切从系统语言开始：先构建一个简单但强大的类 C 系统编程语言。它最初在宿主机上引导（bootstrap），之后用它来构建其余所有软件；最终大部分宿主工具链都能移植到 Bitwise 计算机本机上运行。
2. CPU 上电阶段：当 CPU 首次点亮时，用这门语言编写模拟器（emulator）、汇编器、反汇编器和调试器。
3. 汇编级验证：用汇编语言写测试程序验证 CPU。
4. 编译器后端：CPU 可用后，为系统语言写一个针对该 CPU 的编译后端，开始在它上面运行简单的编译程序。
5. 微控制器级操作系统：构建一个简单的微控制器级任务切换操作系统，并在其上写简单应用。
6. CPU 演进路线：初始是一个功能与性能有限、仅带 UART（用于与宿主通信）的 RV32I 微控制器级核心；随后扩展到 RISC-V 的 RV32G profile（整数乘除 M 扩展与浮点 F 扩展）；为提升性能加入指令流水与分支预测，在有 DRAM 支持后加入缓存；外设方面补齐音视频输出与网络，配套软件与硬件进度并行开发。
7. 终点形态：一个带图形用户界面的桌面级简单操作系统，能运行自己写的游戏和其他应用。在实现 MMU 之后，可以尝试引导 Linux，但这不是主要目标。

README 以此收尾："而这仅仅是个开始！"

六、仓库源码印证：路线图已经走到哪一步

以下各小节以当前仓库的实际代码为证据，展示路线图各环节的落地形态。所有内容均可直接打开对应文件查看。

6.1 Ion 编译器：C99 实现的两遍编译器

路线图的第一个项目——"类 C 系统语言编译器"——就是仓库中体量最大的模块 ion/。整体结构印证了 notes/ion_motivation.md 中的设计：

• 单一编译单元构建：ion/main.c 通过#include依次并入common.c、lex.c、type.c、ast.c、parse.c、resolve.c、gen.c、ion.c、test.c等实现文件，main()只是转调ion_main()。这种"物理耦合"的极简组织方式正是项目"简单性优先"哲学的直接体现。
• 两遍编译：第一遍词法分析与 LL(1) 递归下降解析，产出 AST（ion/lex.c、ion/parse.c、ion/ast.c）；第二遍符号解析、类型检查与代码生成（ion/resolve.c 约 3000 行，ion/gen.c），产出 C 代码。语法与词法细节集中在 ion/syntax.txt（包含 EBNF 文法），示例代码见 notes/example.ion。
• 包系统：目录下所有.ion文件自动构成一个包（见 notes/example.ion 中import foo的注释说明），"约定优于配置"。
• #line魔法：生成的 C 代码中穿插#line 行号指令，使编译报错直接指向 Ion 源文件——对应 notes/ion_motivation.md 中提到的 "#line magic"。实现在 ion/gen.c，可用--nolinesync关闭。

从源码结构看，编译器入口 ion/ion.c 提供了完整的命令行接口（ion/ion.c）：

Usage: ion [flags] <main-package> -o <file> 输出文件（默认 out_<main-package>.c） -os <os> 目标操作系统（枚举，见 targets.c） -arch <arch> 目标机器架构 -check 只做语义检查，不生成代码 -lazy 只编译从主包可达的部分 -notypeinfo 不生成 typeinfo 表 -fullgen 对不可达符号也强制全量生成 -nolinesync 禁用 Ion 代码与生成 C 代码之间的 #line 同步 -verbose 输出额外诊断信息

以及三组环境变量（ion/ion.c、ion/ion.c）：

• IONHOME：Ion 主目录（system_packages所在位置），未设置则报错退出；
• IONPATH：分号分隔的附加包搜索路径；
• IONOS/IONARCH：指定目标操作系统与架构（与-os/-arch对应）。

编译流程还要求主包中定义main入口（ion/ion.c），默认先解析"自然可达"符号，非--lazy时再强制解析全部符号，最后生成 C 文件（默认名out_<package>.c）并打印内存使用统计（intern/source/AST 字节数与比值）。

宿主端与目标端的双轨支持也已在源码中体现：ion/system_packages/ 下的builtin/提供@foreignC 互操作（如 alloc.ion 中的@foreign("tls_alloc")分配器接口）、按平台拆分的types_*.ion/config_*.ion；libc/与sdl/目录则提供对 C 标准库和 SDL 的绑定，正是"宿主端与 C 及宿主 OS 无缝互操作"这一目标的落地。

6.2 RISC-V 工具链：用 Ion 写汇编器

路线图中"CPU 上电时编写模拟器、汇编器、反汇编器、调试器"这一步，仓库已有实质性产出，且全部用 Ion 语言编写：

• ion/riscv/riscv.ion：RISC-V 指令集定义（约 950 行）；
• ion/riscv/assembler.ion：静态汇编器实现（约 2500 行），文件内自带align_up_uint、is_pow2等对齐工具函数；
• ion/riscv/dynasm/dynasm.ion：动态汇编器，对应 notes/streams.md 中 Day 24–26 "RISC-V Dynamic/Static Assembler" 系列直播；
• notes/asm.txt：RISC-V 汇编的笔记（约 960 行）；
• ion/forth.asm：用 RISC-V 汇编实现的 Forth——印证 FAQ 中"顺带学会实现 Forth、Lisp 和内嵌脚本语言等其他语言"的教学承诺。

6.3 Rattle：Python 内嵌 DSL 的逻辑设计

硬件轨的起点"学习数字逻辑 + 自研 HDL"对应 rattle/ 目录：

• rattle/rattle.py（约 1450 行）：DSL 核心，提供@module、input(bit)、output(expr)等原语，用 Python 类与表达式描述组合逻辑；
• rattle/tutorial.py（约 1300 行）：一套完整的逻辑设计教程，从 Xor/Not/NAND 门电路 起步，到真值表转"与或式"（sum of products）、多路选择器（mux）、以及 2 位/3 位加法器、行波进位加法器（ADC）逐级递进——这正对应 README 中"先学数字逻辑，再做小项目"的硬件轨第一步；
• rattle/experiments.py：进一步实验。

FAQ 说明自研 HDL 将以 Verilog 作为综合编译器的中间语言，Python 同时充当硬件设计相关的"万能胶水语言"，这些 Python 原型正是那条路线的起点。

6.4 Noir：用 Ion 写的 GUI 应用

noir/noir/noir.ion（约 800 行）是一个用 Ion 语言编写的图形应用：通过import sdl {...}与import libc {printf, ...}复用系统包，定义了按键到 SDL 扫描码的映射表和基础输入逻辑。它是"系统库（含 GUI）"与"系统应用"两条清单的早期实例，也演示了 Ion 包系统与@foreign宿主互操作在真实应用中的形态。

6.5 进度标尺：streams.md

notes/streams.md 逐日记录了项目直播与工程进展，从 Day 0（Kickoff，2018 年 3 月 12 日）一直记录到 Day 53（"Logic Design, Part 5"）。可以推断：当前仓库快照覆盖的工作进度约到第 53 天，即软件轨已完成 Ion 编译器（含包、类型内省、代码生成）与 RISC-V 静态/动态汇编器，硬件轨刚进入"数字逻辑"教学阶段。这份日志也完整保留了 README 所述"直播 + 博客 + 仓库"三轨并行的运作方式。

七、许可、社区与贡献方式

• 许可：全部代码、数据、文字及相关原创作品进入公有领域（LICENSE.md）。若你的工作直接采用了 Bitwise 的部分成果，作者"会乐意收到一封说明用途的邮件，但你没有任何法律义务"。
• 资金：由作者个人储蓄自持，无资金需求（FAQ.md）。
• 社区规范（GUIDELINES.md）：交流中保持尊重、对新手友好；开放式讨论请使用论坛或 Discord 聊天服务器，GitHub issues/pull requests 只用于具体的缺陷与修复，且须保持中立、建设性的语气；针对"明显仍在快速变动的新代码"提交小 bug 的 PR 通常没有必要，因为下一场直播往往会自然覆盖。
• 如何帮忙：FAQ 给出的现阶段答案是——看直播、帮忙传播、参与社区；作者表示其长期动力很大程度上取决于社区的响应。
• 渠道：项目通过 Twitch 直播、YouTube 视频、博客/文章、论坛与 Discord 服务器对外发布内容（具体入口见 README.md 的 Links 一节与 FAQ.md）。

八、小结

Bitwise 是一个以"凡我不能创造的，我就没有真正理解它"为信条的教学项目：用数年时间、全免费、公有领域地演示如何从零构建完整的软硬件栈——从自研 HDL 与 RISC-V CPU，到类 C 系统语言、内核与桌面 GUI。它的差异化在于两点：一是把"简单性"当作工程决策而非口号（可从 notes/ion_motivation.md 的目标/非目标清单与 ion/main.c 的单编译单元组织方式直接看到）；二是把参与门槛压到最低（只需熟练 C 和免费工具，无需 FPGA 板）。

当前仓库已经展示了路线图的第一块拼图：ion/ 下的 C99 两遍编译器、ion/riscv/ 下的 Ion 语言 RISC-V 工具链、rattle/ 下的逻辑设计 DSL 与 noir/noir/noir.ion 的 GUI 应用。如果你想继续深入，建议按以下顺序阅读：ion/syntax.txt（语言语法）→ notes/ion_motivation.md（语言设计动机）→ notes/streams.md（项目实际推进日志）→ ion/ion.c（编译器入口与命令行接口）。

• 示例工程