最近做的项目是要把vxWorks移植到MIPS R3K处理器上。做这个移植最大的目标是把目前这款产品的成本进一步压缩（虽然现在这款产品的成本已经控制得很低了，但是由于这款产品也是公司出货量最大的产品，如果能把成本进一步压缩，哪怕只能压缩很少一点，也能为公司节省不少的钱）。而完成这个移植过程最大的困难在于，必须严格把构建出来的vxWorks映像的尺寸控制到最小——因为只有512KB的Flash空间可以用。
对于MIPS CPU而言，减小代码尺寸的一种办法是把代码编译成MIPS16指令。常规的MIPS指令是32位长度的，MIPS16指令的长度则是16位，使用这种办法，通常能够把代码尺寸缩小30%-40%（和ARM CPU的Thumb指令能达到的空间节约程度差不多）。但是，并不是所有代码都能编译成MIPS16位指令，因为MIPS16指令只是MIPS32指令的一个子集，比如，对协处理器CP0的操作就无法用MIPS16指令完成。这就意味着：异常和中断处理都必须编译为MIPS32指令。经过分析发现，和体系结构相关的汇编代码（包括异常和中断处理部分的代码）编译之后所占的空间不是太多，不到100KB的样子，因此梁工（也就是主持这个项目的负责人啦）决定把所有汇编代码都编译为MIPS32指令，之外的C代码才编译为MIPS16指令。
但这样并不能解决全部的问题，因为异常和中断处理部分的汇编代码通常会调用以C代码写成的处理函数，这些以C代码形式编写的处理函数也必须编译为MIPS32指令。如果不这样做的话，在最后的链接步骤中链接器就会报错：jump to stub routine without jal，这个报错信息的含义是说：没有使用jal指令实现从MIPS32位模式到MIPS16模式的跳转，这在混合使用MIPS32和MIPS16位指令的情形下是不合法的。
由于存在着上述的这个问题，就要求我们在移植的时候必须识别出哪些C函数是需要编译成MIPS32模式的，并明确地给它们加上__attribute__((nomips16))属性，以确保它们不会被编译成MIPS32指令。我抱怨说：vxWorks源代码中需要做这种修改的地方很多，都去一一手动修改，岂不是太麻烦了。梁工回答：身为工程师，就不能怕麻烦，要是随便找个打扫卫生的都能搞定，那公司还要我们来干什么呢，我们还不早都失业了么。
想想梁工说得也对。工程师的职责就是解决问题，无论要解决问题的是大还是小，是容易还是麻烦，都必须静下心来一一的去解决。
在这个项目尚处于论证阶段的时候，我们曾尝试着用厂商提供的工具链（而不是Tornado里面自带的工具链）来构建出一个vxWorks映像，在这个阶段里面，有很多工作是没法用自动化的办法处理的，必须反复地做“尝试-修改-验证”这个工作，比如，一些编译器选项是Tornado工具链支持的，而该厂商的工具链并不支持，这时就必须想办法去修改Makefile，vxWorks源码所用的Makefile结构颇不简单，有时修改一次得到的结果不正确，还得要反复再找原因，定位问题，寻求解决办法。
再有，由于所用的这款处理器属于MIPS R3K这个比较古老的体系结构，vxWorks源码中的一些汇编指令是这个处理器不能够支持的，这样我们还必须想办法把这些指令替换掉，但编译器每次只能报告出一个位置来，这样，也必须要反复地做这样的修改，虽然vxWorks中跟MIPS体系结构相关的汇编代码不算很多，但怎么算也在几千行以上。当你不知道后面还有多少重复的工作需要做的时候，是很容易烦躁不安的。
最近在调试BSP的时候，也碰到让人非常头痛的麻烦问题，由于我们的ICE仿真器比较“傻”，在大多数时候都不能正确地解码出MIPS16位指令，这样，我们在调试以MIPS16模式编译出来的指令时，在ICE中看到的是32位指令，但实际上却是两条16位指令。这样，没有办法，我们必须拿着反汇编代码和ICE中的指令一一对应着进行调试，其难度可想而知。我曾这样感叹道：调试C代码的时候，觉得读调试器里面的C代码真是痛苦；调试MIPS32汇编代码的时候，觉得原来世间其实还有更痛苦的事；到了调试MIPS16位代码，当发现在调试器里面甚至都看不到CPU实际执行的是什么指令的时候，才觉得原来调试MIPS32汇编代码真可以算是一种享受，而调试C代码简直就可以算得上是身在天堂了。
所有这种种麻烦和痛苦，都是一个工程师必须要面对、无法逃避的。对于软件工程师，尤其是靠近底层的嵌入式软件工程师而言，这样的痛苦和麻烦每天都在发生、重演。如果怕麻烦，就不能够把这些痛苦和麻烦解决掉。工程师只能抱定一个信念：那就是，不管这个软件里的麻烦和痛苦到底有多少，终究都是有限的，只要我耐下心思一个一个地把它们干掉，就一定能有守得云开见月明的一天。大概只有这样，工程师才能从日复一日、年复一年的痛苦纠结中解脱出来，看到解决问题的曙光，进而才能埋头于解决好当前面临的最急迫的问题。
