午休时看到CSDN上的一篇叫’外行人看软件:看<商谍>有感‘的文章，这又让我想起07年看完’虎胆龙威4‘后的那个问题：现在影视著作中表现程序员这个行当的作品太少了，包括书籍杂志也是这样，我记忆里是没看到哪部畅销小说是写程序员的。

隐约记得央视很多年前有一部电视剧叫"牵手"的，那里的主角-由吴若甫饰演的是搞软件开发的，但是剧中基本没有程序员典型生活的描写，主要还是以爱情作为主线。起码这也算是我看到的第一部有程序员这个职业角色的影视剧了。07年的"虎胆龙威4"算是从正面描写程序员(剧中是黑客)的一部好作品了，这部剧也向人们展示了程序员所从事的工作对这个社会的重大意义和价值了。

即使如此，以程序员职业为剧情背景的作品比之其他传统行业来说还是少之甚少，简直少的可以认为是忽略不计。

人民大众对于程序员这个职业的了解应该说少之又少。就拿我自己来说，我工作了3年多，我父母只是知道我每天都是坐在电脑前的，却不甚清楚我到底在做什么？也不知道我做出的东西到底有什么用处，因为在他们的生活里连最基本的对软件的感性认识都没有，想和他们解释清楚难啊。最好的做法就是买一台电脑给他们，连上互联网，让他们去自己感受。像我父母这样在传统思维中生活习惯的人在中国应该说占了大部分。’缺乏群众基础’、行业年轻、少有素材，也许这就是影视书籍作品中少有反应程序员生活的原因之一。就拿"商谍"这部作品来说，据完整看过这部电影的人反映：片中某组场景是描述一个"高智商"的CTO在没日没夜地编写代码，但是其中的一组屏幕特写却反映了此剧导演对程序员的了解。屏幕上展示着如下代码："case 1: a = 3; case 2: a = 4; case 3: a = 5; …" 寒，就一个字啊！这不是低估中国程序员的智商么:)

程序员是一个极具创造力的群体，思维敏捷而发散，天马行空，喜欢新事物，成就感驱动，有时为了自己编出了一段精致的代码而暗自偷乐，成就感三天而不绝。程序员的工作场景很简单-计算机前，很多程序员天生不爱张扬，也就和程序员的工作产品一样，他们被划归为幕后工作者。用挑灯夜战、废寝忘食来形容我们的生活真是一点也不过分。他们编写出来的产品却在社会发展中起着至关重要的作用。股票交易系统、银行支撑和结算系统、电信支撑运营系统、公路/铁路/民航调度指挥系统、社保医保公积金管理系统等等等，这里哪个系统出了事情都是要影响社会和谐稳定的。

程序员已经沦落到了自己操刀来写自己的份了，CSDN最近贴出的’疯狂程序员‘就是一个例子。我真是希望能有几个学文学出身的程序员，兼具很强的文学作品创作能力，多写写咱们程序员，让中国人民了解我们。程序员中也不乏能写的，很多专业程序员也很能写，但是也许他们少有时间来系统的思考和写作罢了。

制作程序员相关的影视、书籍作品的经济投入产出分析：拍出一部好的反映程序员的电影或其他作品应该很有市场，现在的程序员都很年轻，都是社会的消费主力，他们手里的银子很好赚的，只要你能写出、拍出真正反映我们程序员生活的作品。

SIGBUS和SIGSEGV也许是我们在平时遇到的次数最多的两个内存错误信号。内存问题一直是最令我们头疼的事情，弄清楚两个信号的发生缘由对我们很好的理解程序的运行是大有裨益的。

我们来看两段程序：
//testsigsegv.c
int main() {
        char *pc = (char*)0×00001111;
        *pc = 17;
}

//testsigbus.c
int main() {
        int *pi = (int*)0×00001111;
        *pi = 17;
}

上面的代码那么的相似，我们也同样用gcc编译(加上-g选项，便于gdb调试；平台Solaris Sparc)，执行结果也都是dump core。但通过GDB对core进行观察，你会发现细微的不同。第一个例子出的core原因是：Program terminated with signal 11, Segmentation fault. 而第二个例子的core则提示：Program terminated with signal 10, Bus error. 两者有什么不同呢？这两段代码的共同点都是将一个非法地址赋值给指针变量，然后试图写数据到这个地址。

如果要说清楚这个问题，我们就要结合汇编码和一些计算机的体系结构的知识来共同分析了。

先来看testsigsegv.c的汇编码：
… …
main:
        !#PROLOGUE# 0
        save    %sp, -120, %sp
        !#PROLOGUE# 1
        sethi   %hi(4096), %i0
        or      %i0, 273, %i0
        st      %i0, [%fp-20]
        ld      [%fp-20], %i1
        mov     17, %i0
        stb     %i0, [%i1]
        nop
        ret
        restore
… …

我们关注的是这句：stb     %i0, [%i1]
从计算机底层的执行角度来说，过程是如何的呢？%i0寄存器里存储的是立即数17，我们要将之存储到寄存器%i1的值指向的内存地址。这一过程对于CPU来说其指挥执行的正常过程是：将寄存器%i0中的值送上数据总线，将寄存器%i1的值送到地址总线，然后使能控制总线上的写信号完成这一向内存写1 byte数据的过程。

我们再看testsigbus.c的汇编码：
… …
main:
        !#PROLOGUE# 0
        save    %sp, -120, %sp
        !#PROLOGUE# 1
        sethi   %hi(4096), %i0
        or      %i0, 273, %i0
        st      %i0, [%fp-20]
        ld      [%fp-20], %i1
        mov     17, %i0
        st      %i0, [%i1]
        nop
        ret
        restore
… …

同样最后一句：st      %i0, [%i1]，CPU执行的过程与testsigsegv.c中的一致(只是要存储数据长度是4字节)，那为什么产生错误的原因不同呢？一个是SIGSEGV，而另一个是SIGBUS。这里涉及到的就是对内存地址的校验的问题了，包括对内存地址是否对齐的校验以及该内存地址是否合法的校验。

我们假设如果首先进行的内存地址是否合法的校验(是否归属于用户进程的地址空间)，那么我们回顾一下，这两个程序中的地址0×00001111显然都不合法，按照这种流程，两个程序都应该是SIGSEGV导致的core才对，但是事实并非如此。那难道是先校验内存地址的对齐？我们再看这种思路是否合理？

testsigsegv.c中，0×00001111这个地址值被赋给了char *pc；也就是告诉CPU通过这个地址我们要存取一个字节的值，对于一个字节长度的数据，无所谓对齐，所以该地址通过对齐校验；并被放到地址总线上了。而在testsigbus.c里，0×00001111这个地址值被赋给了int *pi；也就是告诉CPU通过这个地址我们要存取一个起码4个字节的值，那么对于长度4个字节的对象，其存放地址起码要被4整除才可以，而0×00001111这个值显然不能满足要求，也就不能通过内存对齐的校验。也就是说SIGBUS这个信号在地址被放到地址总线之后被检查出来的不符合对齐的错误；而SIGSEGV则是在地址已经放到地址总线上后，由后续流程中的某个设施检查出来的内存违法访问错误。

一般我们平时遇到SIGBUS时总是因为地址未对齐导致的，而SIGSEGV则是由于内存地址不合法造成的。