技术奇异点

自从 2 月份研究了投射矩阵（projection matrix）之后，学习 OpenGL 的事情就放下了好一阵子。直到最近工作上有了实际的需求才重新拾起来。

附带说一下，《OpenGL SuperBible》这本书真的不错，虽然已经多少年对名字含有『Bible』的书敬而远之了。不过纠结了很久是买第四版还是第五版，因为第五版把 OpenGL 3.0 里标为 deprecated 的 fixed-pipeline 部分删除了。但是短期内不好说 OS X 对 OpenGL 3.0 能支持到什么程度。而且实际中也要尽量支持 Windows ，那是个对高版本 OpenGL 更严酷的环境。

每次看 OpenGL 都觉得它的编程风格透着股邪气，这当然有我本人经历的缘故，但也主要是因为 OpenGL APIs 对参数和返回值的使用相对一般的编程风格来说比较少，而对当前状态（current context）的依赖相对较多。比如说纹理贴图操作（texture），一般的风格是把作为纹理的位图载入内存，然后返回一个纹理对象的引用或者 handle ；然后调用贴图的函数，把纹理对象和被贴图的对象作为这个函数的参数（或者贴图函数就是被贴图对象的一个方法）。OpenGL 里，一般先用一个函数把位图调入内存创建一个『当前』纹理对象。但是没有任何引用或者 handle 表示『当前』纹理对象，后续的贴图操作仅仅依靠『当前』这个状态本身来操作。再比如向一个多边形添加一个顶点（vertex），没有任何引用表示这个多边形，你能依靠的只是『当前』多边形。当然用过的人对此也不会太奇怪，因为 OpenGL 标准开宗明义 OpenGL 是一个『状态机』模型。

我初次接触 3D 开发是 7 年前的 Java 3D，使用的是和 OpenGL 完全不同的概念模型，虽然用的是 Java 语言，但是更接近声明式的风格。这也是我觉得 OpenGL 邪门的一个原因。

要说这个概念也不是那么难懂，但是为什么会透出一种邪气呢？我猜大概是从高级语言诞生以来，程序员已经习惯了用参数和返回值进行跨函数的信息传递。而高度依赖上下文属于上一代语言，也就是汇编语言的编程风格。

在高级语言中，借助符号化的变量和逻辑化的语法，可以毫不费力的在一行代码里访问五六个甚至十来个变量。所以借助于这些直接访问变量之外的隐式上下文在高级语言里成为了不必要的事情，尤其因为隐式上下文是加大程序局部复杂度的主要原因。而汇编语言则恰恰相反，需要通过好几条甚至几十条指令才能完成高级语言一行的功能，而每条指令只能操作一两个操作数。所以隐式上下文是不可缺少的。

因为采用状态机模型和汇编的编程风格，所以基于 OpenGL 编写的代码颇有些奇异的风格。比如，今天的代码很少在语法结构之外采用缩进，也就是说，除非是语法级别的结构，比如类的定义、分支、循环、函数定义、或者命名空间等等，一般的语句不会采用缩进。而在基于 OpenGL 的代码里，基于上下文变化的缩进是普遍的习惯。OpenGL 虽然提供 C 函数作为 APIs ，但是本质上和形式上都是显卡的汇编语言。在对性能要求极高的 3D 领域，虽然形式上通过 C 语言提供了跨平台能力，本质上却重演了早期计算机开发注重性能的汇编语言阶段。

OpenGL 的汇编风格还我想到一个在网上讨论中遇到过两三次的观点：声明式（declarative）的 DSL（domain specific language）具有广泛的未来，特别是声明式语言给底层平台的全局优化留下了巨大的空间。OpenGL 的目的是描述一个场景（scene），从问题本身来说是一个非常适合声明式 DSL 的任务，从机制来说也需要最大化利用硬件优化。但 OpenGL 并非声明式而是命令式（imperative），而且并非高级语言的过程式结构化风格而是偏重于汇编风格，我想这也是现实向理想低头的一个例子，毕竟只有程序员才能从各个层次考虑优化。

⋯⋯ 太多时候，用 printf 或者 log 就能发现问题。一些人于是发誓只用这种方法，而且如人所愿，只要时间充裕，力气下足，其实不用 debugger 也能干活。

—— Kernel Programming Guide

十年前刚毕业的时候，在公司里被分配了第一个像样的任务：用 Java 写一个 GUI editor 。准备开发环境的时候遇到一个问题： 对当时的我来说，和 Visual C++ 之类的工具相比，JDK 的 debugger 太难配置了。另一方面，System.out.println 倒是唾手可得的『利器』。最终我完全用后者调试完成了那个 5000 多行的 GUI editor 。之后的七年里我几乎再没有碰过任何 debugger 。对它的全部认识就是设置断点，运行程序 hit 断点之后单步（step in/over）。每次搭建开发环境的时候似乎都会因为因为这样那样的原因而放弃使用 debugger ，printf，println 乃至 log 文件是不二的应对法宝。

直到三年前重新回到 Visual Studio 和 Xcode 的 IDE 环境之后，抱着反正不用费力气配置直接可以用的态度重新拾起 debugger 。下面是大致按照时间顺序的发现：

第一条：call stack

最初七年里无数次从 Java exception 的 stack trace 里获得解决问题的线索，也在研究 Linux 代码的过程中意识到能随时了解 call stack 的好处，可是我从把 call stack 和 debugger 联系上。重拾 debugger 之后的第一个新认识是它的作用不光是单步，更重要的是可以揭示 call stack 。如果没有 debugger 和 call stack ，阅读已有的 code base 的难度会提高一个数量级。

第二条：死锁

多线程问题和性能问题被我认为是 debugger 一无用处而非 log 不可解决的难题。直到两年前对着一个debug 状态下僵死的程序做了一个 pause 操作，debugger 显示的 call stack 稳稳当当的停在了死锁的位置。

第三条：UI 操作

UI 问题被认为是最容易应用 debugger 的，因为一般来说触发断点最直接，而且线程也不多。但是遇到 debugger 会干扰程序本身的 message queue 的时候就束手无策了。为了尽量避免手工加入 logging 代码，也找了各种土办法减少 debugger 对 message queue 的干扰。

比如，如果在窗口绘制代码中设置断点，就会让 debugger 在绘制窗口的过程中夺取焦点，continue 之后又会把焦点返回原来的被调试程序的窗口，在 Windows XP 上就会又触发窗口绘制。而 OS X 和 Windows Vista 的 buffered window 能让窗口绘制的代码不会像 Windows XP 里的窗口那样每次在 debugger 把焦点交还的时候都触发窗口绘制。尽量利用不同系统的消息处理差异来找到最合适解决问题的环境。

但是这些方法都要靠系统实现的差别和被调试程序逻辑的机缘巧合，并非每次都能成功使用。无法找到一定之规，有的情况也根本没有办法。比如，有些控件会处理失去焦点的事件，用如果在处理失去焦点的代码里加入断点，调试起来就很难分别哪些事件是正常情况下会发出的，哪些是受 debugger 的干扰发出的。

困惑了两年多之后终于发现处理 UI 调试的方法其实简单得令人发指。只要能找到纯命令行的 debugger（比如 gdb，Flash 的 fdb），用 ssh 或者 telnet 从另一台机器登录到被调试程序所在的机器，用命令行 debugger 调试就行。这时，任何断点的中断都是通过后台协议传递给 ssh/telnet client 上的终端而不会干扰被调试机器的 message queue 。回顾过去的十年，很惊讶被这个问题困扰了那么长时间的不光是我，还有我询问过的几乎所有同事，几乎每个人处理这种问题都是依靠 log（不得不说有些人，比如志岩还是提出了 remote debugging 的思路，但是很可惜只是一个灵感而不是整套解决方案）。

第四条：条件断点

如果一个断点的第一次、第二次、⋯⋯ 第 n 次被 hit 的时候你都并不想单步或者检查状态怎么办？当然可以多点几次 debugger 的 continue 按钮，让真正期待的第 n+1 次 hit 到来。但是如果第一次的 hit 会干扰第二次呢？（我听见有人说可以用 ssh+命令行 debugger 调试。不过大多数情况没有必要祭出 remote debugging 。）又或者 n 是 10000 怎么办？为了对付这种情况用了不少土方法，比如临时给被调试的程序代码增加一个分支特地用来设置断点，或者在程序弹出 modal dialog 的时候设置断点。

其实 gdb 一类的 debugger 一直都有条件断点的功能。可以让一个断点并不是每次 hit 的时候，而是满足一些额外条件的时候才中断，比如第 n 次被 hit ，或者一个变量大于某个值，或者一个 C 函数的返回值符合条件的时候 ⋯⋯

第五条：监视变量

你是否曾经大声咒骂过：这个变量到底什么时候被改动的？然后不得不一步步的 step over 查看，发现值发生变化之后，停止调试，重启程序，重复刚才的 use case ，step over 到刚才的地方，step into ，然后再 step over ⋯⋯

其实 gdb 和很多 debugger 都能自动监视变量的变化，并且在变化符合某种条件的时候自动中断。条件的配置和条件断点一样灵活。而且 x86 CPU 为了支持这种功能特地设置了几个 debugging resigter （32 位下四个，64 位下更多），所以监视变量几乎不会影响调试速度。不用这个功能都对不起 x86 CPU 上那些专门用来 debug 的硅。

第六条：Log

最终，还是会有些问题确实需要在不间断的执行中监视某些状态。也就是 log 。可是 log 必须得是在代码里加入 printf 吗？gdb 的 commands 命令让断点在 hit 的时候可以执行一段命令，任何合法的 gdb 命令，比如打印某个变量之后 continue 。

结论

… In many cases, you can find the problem through careful use of printf or IOLog statements. Some people swear by this method, and indeed, given sufficient time and effort, any bug can be found and fixed without using a debugger.

—— Kernel Programming Guide

接受 debugger 是一个抛弃原有成见的漫长过程。一开始我们总认为自己的土方法是最有效的（因为当我们抱着进入尖端领域的心情开始软件开发的生涯时，周围的前辈总会教你几个土方法）。然后我们知道真的有先进的工具。我还远远未了解所有 debugger 的所有功能。但是配置一个 debugger 是将我在所有开发平台上的第一件事。

研究过 32 位 Linux 内核的人都知道这个内核著名的 3G/1G 划分：低 3G 作为用户态空间，高 1G 作为内核态空间。内核态和用户态共享 4G 的 32 位地址空间。

这个划分成了 32 位内核的基本设计方式。Windows 内核也采用类似的划分（缺省为 2G/2G 划分，可以通过启动参数改为 3G/1G）。所以，可能很多人像我一样，很自然的把这种划分当成了内核的必要设计：内核态和用户态必须共处在同一个地址空间里；似乎如此内核才能管理用户态的内存。见到 Mac OS X 内核 XNU 的设计颠覆了我的观点。XNU 的内核态独占 4G 内核空间，而非与用户态共享。（如下左图显示。）

如果不是因为一个采用如此设计的内核就摆在面前（而且已经在上面工作了三年），我几乎不会想到内核的地址空间还能如此设计。看到这个设计的同时也豁然开朗：一开始认为『内核态和用户态必须共处在同一个地址空间』才能让内核『管理用户态的内存』的想法实在是短路。内核并不能了解用户态如何使用内存，更重要的是，内核并不能信任用户态内存的内容。所以，它根本不能通过和用户态『共处在同一个地址空间』这种方式来管理后者的内存空间。因为『共处在同一个地址空间』提供的唯一功能只是可以直接通过线性地址访问（也就是俗称的裸指针），而内核绝对不能碰用户态的裸指针。内核管理用户态内存的方式只能是通过设置页表和页目录来保证用户态的内存访问的合法性和一些特殊映射。

再者，Linux 和 Windows 下与内核共享地址空间的用户态只能是当前运行的进程。如果是通过系统调用进入内核，还多多少少可以说这时的当前进程和内核的关系比其它进程密切一些。如果是通过中断（时钟或者I/O）进入的内核，这时哪个进程是当前进程对内核来说完全是巧合。更何况无论如何内核也不可能只管理当前进程的内存空间。所以从这个角度说共享地址空间对内核管理用户态内存也没有帮助。

退回到 Linux 和 Windows 的设计，为什么还要让内核与用户态共享地址空间呢。其实是因为尽管每次进入内核态都可能发生进程切换，但是大多数情况下并非一定发生这样的切换。因此，共享地址空间可以避免进出内核态的时候进行地址空间（cr3）的切换。在 x86 构架下，切换地址空间要导致所有 TLB 失效，CPU 必须访问主存更新 TLB。所以，共享地址空间是一个性能 hack，仅此而已。这个性能 hack 如此历史悠久，以至于有些人如我一般完全无法想像还能有其它方式。

不过，XNU 的内核地址空间也并非和用户态空间绝对分离。在每个用户态地址空间的最高几兆也被保留为内核空间（如上右图所示）。这是因为从用户态切换到内核态（通过软中断或者比较新的 x86 syscall 指令）时，并不能同时切换地址空间，所以必须保留这段短短的共享空间来完成地址空间的切换。其实，我们可以把这个设计想像成一个处于 micro-kernel 和 monolithic kernel 之间的中间设计。和 micro-kernel 类似，内核也享有独立空间，但是和 monolithic kernel 类似，整个内核都是处在特权级，没有从微内核到内核服务的二次切换。

对于词典软件来说，发音是个必需具备的基本功能，而且 dict.cn 的 Web API 提供了 MP3 格式的单词（短语）发音，所以从开始写 Dict Mac 的起，发音就被列入计划加入的功能。0.02 版完成之后，也就是从 5 月 25 日左右开始准备实现发音功能。

最初的问题是找到合适的 API，花了一个晚上，从 blog 和论坛的帖子堆里发现无数名称，逐一在 Apple 的文档里查找印证，最后终于锁定 Audio Queue Service 这个 framework。有了 framework 的确切名称后就不必再流连于 Stackoverflow 之类的网站，开始专心阅读 Apple 的文档。

花了一个晚上草草看了一下《Audio Queue Service Programming Guide》，感觉不是很好。这个 framework 功能比较强大，设计得比较灵活，相对来说也就没有提供傻瓜化的播放 API，即使是播放一个 MP3 文件也要 400 多行代码。好在这些代码在 programming guide 里都已经直接给出。但是一来我不喜欢这种 copy/paste 代码的方式，二来如果这些代码有 bug（当然 programming guide 里的代码本身有 bug 的可能性不大，但是和 Dict Mac 的 code base 集成的时候很可能引入问题），也要花不少时间解决，而且很可能要重读 programming guide 甚至查阅 API reference。

另外的问题是选择把 dict.cn 的 MP3 文件 download 到本地文件系统之后再打开文件播放的方式，还是直接播放网络的流数据的方式。从尽量减小暴露给用户的复杂度的角度说，稍稍倾向后者。但是考虑到今后还要实现本地缓存，以及尽早实现功能，还是决定先写出把 MP3 文件按照单词作为索引存储在本地文件系统的代码。花了两个晚上写好了这些代码后，第二天白天我脑子里突然冒出一个问题：OS X 会不会有现成的播放 MP3 的命令行工具？从以往的经验看，OS X 的命令行工具还是相当强大的。Google 了一下，果然有一个 afplay。这样一下子把实现发音功能的剩余工作从至少两个晚上变成了一个小时 —— 只要 fork 一个新进程运行 afplay 即可。

其实刚开始写 Dict Mac 的时候就考虑过是不是把必要的 UI 之外的其它功能都做成一个后端独立进程。最后决定当前阶段还是写成一个进程。不过 afplay 至少让发音功能成为了一个独立的进程。一开始我还在抱怨为什么 Mac OS X 不能直接提供一个播放 MP3 的傻瓜接口，其实这样的傻瓜功能应该做成工具而不是 API，像 Audio Queue Service 那样灵活的接口才值得作为 API 的形式提供。这个事情上 OS X 继承了 UNIX 的精髓，也是像 Windows 这样的不管底层功能还是傻瓜功能一股脑的做成 API 的非 UNIX 类的 OS 最缺乏的文化。

Diff 是程序员最重要的工具之一。不过，除了在 mail 里发送 patch，我很难忍受传统 diff 的字符输出。在任何系统上开发软件，第一件重要的准备工作就是寻找趁手的 GUI diff 工具。GUI diff 工具的优势在于 side-by-side 的比较方式即能显示变化的部分，又不影响对每个版本的连续阅读。Linux 上比较好的是 KDE 的 kompare，也是我见到的第一种 GUI diff 工具。因为先入为主的看到 kompare 使用曲线来联系变化的对应关系，所以任何使用空行填充或者直线来显示对应关系的 GUI diff 工具对我来说也是比较勉强的 —— 可以暂时使用，但是仍然会不断寻找替代品。

平时工作用 Perforce 管理代码，它有个自带的 GUI diff 工具 P4merge。功能很强大（而且免费，虽然 Perforce 是商业软件，但是它的 client，包括 P4v 和 P4merge 都是免费的，而且 P4merge 可以完全脱离 Perforce server 独立使用），除了普通的比较两个文件（版本）之外还可以 3-way 比较（一般用来做人工的 branch merge，分别比较 branch fork 之前的原始版本，main branch 上的修改版本，和其它 branch 上的修改版本）。和 editor 不同的是，diff 工具操作的不仅仅是 check-out 的 version，而是 version repository 里的任意版本。所以 diff 工具要想和 version control 系统配合，简单的文件操作是不够的，一个成熟的 version control 系统必须在设计中考虑如何与外部的 diff 工具协作。

从上周开始用 Git 管理 Dict Mac 的 code base。用到昨天终于感到缺省的『 git diff 』不好用（类似『 diff -u 』的输出）。简单的 Google 一下就找到了答案：

git difftool …

原本以为只有在 Linux 上才会有缺省配置好的 GUI diff 工具和 Git 协作。在 Mac 上试过发现 OS X 上已经配置好了 opendiff 可以让 Git 直接使用。OS X 的 out-of-box 用户体验确实不是只用来蒙初学者的。连 developer 的工具也能准备齐全。但我还是最习惯 P4merge。于是试着配置：

git config –global diff.tool p4merge
git config –global \
difftool.p4merge.cmd /Applications/p4merge.app/Contents/MacOS/p4merge

然后运行『 git difftool 』，P4merge 是调用起来了，但是没有内容。原来 Git 缺省不会向 diff 工具传递参数，必须写到命令行配置里：

git config –global \
“difftool.p4merge.cmd \
/Applications/p4merge.app/Contents/MacOS/p4merge \”\$LOCAL\” \”\$REMOTE\””

这里还有一个陷阱，在某些 shell 里，『 $ 』是不用加转义的。不过在 OS X 的 bash 里必须加。

把 Dict Mac 介绍给同事们之后遇到最多的回应是『怎么是 10.6 only 的？』我喜欢用最新的东西，加上在家里测试 10.5 也并不方便，所以开发的时候没多想就选了 10.6 SDK。没想到连公司同事这些 Mac 的重量级用户还有不少没升级到 10.6，于是今天中午花了一个小时把最低平台需求降到了 10.5。其间遇到了几个小问题。

第一是 NSApplication 的 delegate 在 10.5 之下没有类型，在 10.6 下则正式定义为 NSApplicationDelegate 接口。不过真正起作用的 selector 都没有变化。把 delegate 的基类从 NSObject <NSApplicationDelegate> 变成 NSObject 之后就解决了问题。第二个问题是 NSTextView 的背景色设置成 [NSColor clearColor] 在 10.6 下工作的很好，到了 10.5 下就变成了黑色，变成 [NSColor windowBackgroundColor] 才行。虽然效果相同，但是从正常思路来说我是希望让控件的背景透明，而不是让它『碰巧』和窗口同色，而且遇到那些背景色可以在运行的时候定制的窗口，非透明的控件还要多写代码来同步颜色。

上面两个问题解决之后，Dict Mac 就可以正常的用 10.5 SDK 编译了，在 OS X 10.6.2 上运行也一切正常。之后遇到的问题最离奇，程序在 OS X 10.5 上启动后就会崩溃，crash log 报告 selector [DictWindow awakeFromNib] 不存在。Google 之后发现遇到类似问题的人不少，唯一找到的 workaround 是把 [DictWindow awakeFromNib] 里的 [super awakeFromNib] 去掉（完全莫名其妙的改法，这是一个人记得刚刚升级到 Xcode 3.2 的时候并没有这个问题，然后从自己的 version control 找到当时的代码才得到的解决方案）。

降级 SDK 总会遇到一些小麻烦。也能从中看到 SDK 的每次升级都确实给开发工作减轻了不少负担，唯一遗憾的是用户们升级得没有那么快，新 SDK 的推出带来的好处要过上一段不短的时间才能让开发者受益。