编译点滴 http://www.lingcc.com 关注编译器,虚拟机,编程语言及技术,IT职业和程序员生活 Sun, 05 Sep 2010 06:18:01 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 extern inline问题 http://www.lingcc.com/2010/09/05/11185/ http://www.lingcc.com/2010/09/05/11185/#comments Sun, 05 Sep 2010 06:16:50 +0000 erlv http://www.lingcc.com/?p=11185 继续阅读 →

相关文章：

]]> 用了很久的编译器，在编译新的源程序时，其中一个动态链接库.so文件，忽然报undefined symbol错。很是奇怪。于是，查之。

首先报错的symbol是C++ name mangling(为了防止重名，对程序中名称做特殊处理)之后的，C++filt转换之后，把符号名在源码中grep了一把，发现是个函数名。这个函数名定义如下：

inline fun_name() {
...
}
在另外一个文件中有对该函数的引用，于是有这个声明： extern inline fun_name().问题就出在这个extern inline上。
标记了inline的函数可以接着标记extern吗？
什么是inline，一个函数被标记为inline之后，编译器就会在该函数的被调用点，使用函数体替代调用点。参数采取重命名的方式来防止变量名冲突。这样避免了函数调用的开销，能提升性能，但同时会增加可执行程序的大小。
什么是extern, extern 告诉编译器，某个函数/变量的定义可能在其他的C++源码文件中，编译器在编译时，就直接生成一个函数调用点，只在链接时在其他文件中查找该函数/变量的定义。
两个能同时用于定义一个函数吗？能，但是不同的编译器处理方式不同，在MAC OS系统下，IBM XL C/C++编译器中，若该函数声明在头文件里，就直接视为extern声明。而在gnu 编译器中，则直接视为inline声明。 “extern inline“在C++的标准里没有定义，所以各个编译器如何实现都不同。最好不要这么用。

因为inline是为了性能，所以去掉inline关键字后，这个bug也就过了。

教训就是：写程序一定要有标准，编译器不好做。是是非非不好衡量。还得有标准才行。
参考：

  1. http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc07cplr243.htm
  2. http://www.greenend.org.uk/rjk/2003/03/inline.html
  3. http://stackoverflow.com/questions/216510/extern-inline

相关文章：

]]> http://www.lingcc.com/2010/09/05/11185/feed/ 3 移植软件到64位系统 http://www.lingcc.com/2010/09/03/11176/ http://www.lingcc.com/2010/09/03/11176/#comments Fri, 03 Sep 2010 05:47:05 +0000 erlv http://www.lingcc.com/?p=11176 继续阅读 →

相关文章：

]]> Linux是首个能用在64位处理器上的跨平台操作系统。64位系统在服务器和桌面领域非常常见。所以对于开发者来讲，如何让自己的软件能在32位、64位机上都能工作，是个需要重点考虑的问题。Linux系统使用LP64标准，即，除了指针和long整型是64位外，普通整型仍未32位。因此，对于C语言程序，要重点检查。

64位系统有啥好处，为啥一定要移植？32位系统在大型应用上，给开发者带来和很多挑战，如数据库。还有那些开发者需要尽可能从硬件中获得加速和好处的程序。另外，科学计算通常需要浮点算术，一些财经领域的计算要求比普通浮点计算更高的精确度，更小的置信区间。而64位机恰好能满足这些需求。另外一方面，32位的指针只能标示4G的虚拟存储空间，虽然现在Linux内核能支持大于4G的内存识别，但实际上每个程序可用的内存空间仍然只有4G，若想突破这个局限，要么增加软件的复杂度，性能下降，要么采用64位系统。

另外，日期表示也是个问题，32位机上，使用32位的整数表示系统时间距离1970年1月1日的秒数，若超过2038年，这个整数就会溢出。但如果改用64位表示，起码我们这辈子就不用担心这个问题了。

总的来说，64位系统的优点：

  1. 64位应用可以直接访问2^64字节的内存。
  2. 64位机可以让单个文件大小达到4^63字节，这样大的数据库服务器就可以应用了。

对比64位和32位系统：

  • 32位Linux中，char 8bit, short 16bit, int 32bit, long 32bit, long long 64bit, pointer 32bit
  • 64位Linux中(以LP64标准为例)，char 8bit, short 16bit, int 32bit, long 64bit, long long 64bit, pointer 64bit

32位和64位系统最大的区别主要在数据对象的大小方面。编译器一般会根据数据类型，做自然对齐处理。即，32位的数据类型在64位系统上，会按32位对齐，64位数据类型则以64位边界对齐。对于结构体和共用体，在32位和64位系统上会有不同。 另外，因为64位系统也有不同的标准，如LP64、LLP64、ILP64.所以这些系统之间的区别也需要注意。

因为编译器要对数据做自然对齐，所以编译器需要使用填充(padding)来确保对齐。例如，下面的代码：
struct test {
int i1;
double d;
int i2;
long l;
}
在32位和64位系统上的表示如下：

结构体成员 在32位系统上的大小 在64位系统上的大小
struct test {
int i1; 32-bits 32-bits
32-bits 填充
double d; 64-bits 64-bits
int i2; 32 bits 32 bits
32-bits 填充
long l; 32 bits 64 bits
}; sizeof(test)=20 sizeof(test)=32

从32位系统到64位系统的移植：

容易出问题的几个地方：

  • 声明：尽量使用“L”和“U”后缀声明函数(译者注：“L”和“U”参考)；能用无符号数就用无符号数；如果有在这两个平台上都为32位的整型，使用int定义；若需要某个变量在32位系统上32位，在64位机上64位，使用long定义；对了对齐和性能考虑，使用int和long定义数值变量；使用字符指针和字符时，使用unsinged定义来避免8位符号扩展带来的问题。
  • 表达式：C/C++中，表达式都基于相关性，使用的操作符和算术转换规则。所以，请尽量遵循以下规则：两个有符号int的加保存到signed int中；一个int和一个long的加保存到long中；一个操作数为signed另一个为unsigned，使用unsigned保存；int和double的加，结果保存到double中。
  • 赋值：因为指针、int和long在64位系统上大小不同，所以变量的赋值和使用方式可能会带来问题。不要把long赋值给int，这样可能会丢失高位信息；不要使用int来保存指针，因为64位机上，指针是64位的，int是32位的；同时也不能用指针保存int；基本上这类问题都是因为数据表示，int、unsigned、long。尽量使用表示范围较大的类型，能避免不必要到麻烦。
  • 数据常数：16进制的常数通常用于做标记或者指定特定位的值。比如常数OXFFFFFFFFL声明signed long，在32位系统上，所有位为一，但64位系统上只有最后32位设置了，结果是OX00000000FFFFFFFF.对于有符号数，这明显是不对的。如果你想把所有的位置1，可以使用long x = -1L; 另外，通过移位来设置最高位的时候也要注意，采用1L << ((sizeof(long) * 8) -1); 可移植性更强。
  • 大小尾端：大小尾端说白了，是一个数据如何存的问题。小尾端把数据的低位存在存储位置的低位。大尾端相反。当使用位标记，对某个数据对象用间接指针切分的时候，要特别注意大小尾端的问题。网络子系统提供了htonl、ntohl、htons、ntohs用来做大小尾端转换。但这些是针对32位和16位数据的.另外，还有一些宏，bswap_16, bswap_32, bswap_64来做转换。
  • 类型定义：建议不要使用那些在32位、64位机上大小不同的数据类型，而是采用定长的数据类型。如int32_t, uint32_t(确定长度)、size_t(传参给malloc和free的时候使用sizeof),另外还有ptrdiff_t、intptr_t、uintptr_t。
  • 移位：没有指定类型的整型常数，默认int或者unsigned int型。在移位的时候要小心。
  • 格式化字符串：printf和其他相关函数也有问题。32位平台上，使用%d来打印int和long都没问题，但64位平台上，long会被切去高32位，所以最好使用%ld来打印。同样，当一个小整型(char,short,int)传给printf时，会被展开成64位，所以最好使用%p而不是%x来输出16进制的数。%p是打印一个指针地址，%x只是以普通的十六进制打印。
  • 函数传参：在函数传参时，要注意一些隐含的强制类型转换。还有函数的返回值。

结论

基于性能、性价比和扩展性的考虑，很多平台提供了64位系统支持。32位系统对最大4G虚拟内存的限制，让许多公司不得不考虑64位系统。知道把系统移植到64位平台上，一些注意事项，将让你写出可移植而且高效的代码。

PS:这篇文章是自己学习之用，IBM有更完整的翻译版本，请参考：http://www.ibm.com/developerworks/cn/linux/l-port64.html

参考：

相关文章：

]]> http://www.lingcc.com/2010/09/03/11176/feed/ 0 M9系统独立自主-佩服j.wong-持消极态度 http://www.lingcc.com/2010/09/01/11170/ http://www.lingcc.com/2010/09/01/11170/#comments Wed, 01 Sep 2010 11:38:20 +0000 erlv http://www.lingcc.com/?p=11170 相关文章：]]> 一直关注M9，几乎每天都会去魅族论坛逛逛，看看j.wong又爆了什么料。从M8做到M9，不容易。今天的料更大，M9要深度定制系统，摆脱Andorid，但会兼容Andorid的软件。佩服这位白手起家，敢想敢干的老总。

细数各个手机生产商，几乎都有在Andorid系统的基础上做修改。HTC的htc sense，三星也有自己的定制界面，摩托也有少量定制。但这些貌似都没有在原系统上大改。唯独国内各家，都在深度定制，移动的Ophone，联想lephone中的系统。虽然在努力独立自主，但都挺不容易的。且前途都不乐观。

Andorid是所有系统的基础，不管是媒体炒作还是厂家宣传，都会先说是基于Andorid。那么Google在上游，有任何针对Andorid的版本升级，都会带来网上铺天盖地的，是是非非的各种炒作。譬如现在的lephone基于Andorid 1.6，虽然Andorid 2.2已经存在，但lephone的深度定制版系统升级迟迟没有来。为何？底层系统不像深度定制那么简单。加几个应用，几个程序就能了事。操作系统调试，软件兼容，都将是很大的问题，未来的手机也将和今天的PC一样，归根到底，软件的多少决定系统的成败。个人PC上的操作系统，虽然曾经有很多。但到了现在，几乎只有Linux和Windows了。即使在服务器市场上，Linux也在抢占unix的市场。每次上游的系统升级，带来的炒作，必定会影响用户对下游深度定制系统的看法。手机是个人消费市场，受媒体影响大。譬如Andorid 2.2相对预Andorid 1.6中JIT和WIFI热点的支持，在稍微有点了解的用户看来，都是lephone的劣势。而上游系统升级，也会带来定制系统的二次开发。这也是一笔不小的投入。如何降低后期上游系统升级带来的研发成本，是个问题

另外，使用Andorid系统的，多为喜欢折腾的极客一族，这种人有洁癖，喜欢开源，喜欢原汁原味，有强烈到控制欲，譬如本博。所以，不能使用原生系统，势必会让M9在大多数Andorid一族眼里，大打折扣。如何博得这一部分人的欢心，是个很大的挑战。

硬件方面，Google很可能日后和芯片厂商合作，对Andorid系统做底层的优化。这种性能提升也决定了手机制造商要采用芯片厂商的方案，降低研发成本。另一方面，深度定制的系统也需要随着芯片的升级而改进，才会有持续的性能提升。Wintel的联盟，就是这样一步步建立起来的。如何游离于芯片厂商和上游系统之间，是个挑战。

魅族是家有理想的企业，本博也一直在苦等M9.但今日看到M9要自主，心情复杂，一方面担心，一方面支持。不过支持更多。有中国的企业敢于挑战并且有信心挑战所谓的国际化大公司。希望魅族能看清形式，走好每一步。稍有不慎，就有可能全盘皆输。我们的优势在于强大的市场，和已经很不错的技术积累。

PS:魅族会是有一个联想？还是下一个苹果？或者一个全新的商业模式。拭目以待。附M9近照一张。

相关文章：

]]> http://www.lingcc.com/2010/09/01/11170/feed/ 5 open64中的gcc前端 http://www.lingcc.com/2010/08/23/11157/ http://www.lingcc.com/2010/08/23/11157/#comments Mon, 23 Aug 2010 13:09:29 +0000 erlv http://www.lingcc.com/?p=11157 继续阅读 →

相关文章：

]]> 概述

open64的强项在后端优化，为了避免重新开发，使用了gcc的前端。编译器能发现的大部分错误在词法和语法分析中。所以使用gcc的前端，能让open64具备和gcc一样强大的查错功能。
Open64历史上使用过三个版本的gcc前端，gcc3.3， gcc4.0和gcc4.2. gcc3.3是open64目录下对应的kgccfe(gcc前端)和kg++fe(g++前端).现在几乎都使用最新的gcc4.2,前两个版本几乎已经废弃。所以将以gcc4.2前端为例介绍之。
先上一段代码：
$ opencc hello.c -keep -show
/home/open64/local/open64/open64-gcc-4.2.0/bin/gcc -D__OPEN64__="4.2" -D__OPENCC__=4 -D__OPENCC_MINOR__=2 -D__OPENCC_PATCHLEVEL__= -O2 -D__OPTIMIZE__ -m32 -xc -isystem /home/open64/local/open64/include/4.2 -isystem /home/open64/local/open64/include -E -msse2 hello.c -o hello.i
/home/open64/local/open64/lib/gcc-lib/x86_64-open64-linux/4.2/cc142 -O2 -fi386-host -fcxx-openmp -msse2 -dx -quiet -m32 -fpreprocessed -fbuiltin -dumpbase hello.c hello.i -spinfile hello.spin
/home/open64/local/open64/lib/gcc-lib/x86_64-open64-linux/4.2/wgen42 -fS,hello.spin -fB,hello.B
/home/open64/local/open64/lib/gcc-lib/x86_64-open64-linux/4.2/inline -PHASE:w:c -O2 -show -TARG:abi=n32 -LANG:cxx_openmp=on -fB,hello.B -fI,hello.I hello.c

/home/open64/local/open64/lib/gcc-lib/x86_64-open64-linux/4.2/be -PHASE:w:c -G8 -O2 -show -TARG:abi=n32 -LANG:cxx_openmp=on -LANG:=ansi_c -TARG:processor=opteron -TARG:sse2=on -TARG:mmx=on -TARG:sse=on -TARG:sse3=off -TARG:3dnow=off -TARG:sse4a=off -TARG:ssse3=off -TARG:sse41=off -TARG:sse42=off -TARG:aes=off -TARG:pclmul=off -TARG:avx=off -TARG:xop=off -TARG:fma4=off -fB,hello.I -s -fs,hello.s hello.c
Compiling hello.c (hello.I) — Back End
Compiling vprintf(0)
Compiling getchar(1)
Compiling fgetc_unlocked(2)
Compiling getc_unlocked(3)
Compiling getchar_unlocked(4)
Compiling putchar(5)
Compiling fputc_unlocked(6)
Compiling putc_unlocked(7)
Compiling putchar_unlocked(8)
Compiling feof_unlocked(9)
Compiling ferror_unlocked(10)
Compiling main(11)

/home/open64/local/open64/open64-gcc-4.2.0/bin/gcc -m32 hello.s -c -o hello.o
/home/open64/local/open64/open64-gcc-4.2.0/bin/gcc -m32 -L/home/open64/local/open64//lib/gcc-lib/x86_64-open64-linux/4.2/32 -Wl,-rpath,/home/open64/local/open64//lib/gcc-lib/x86_64-open64-linux/4.2/32 -Wl,-rpath-link,/home/open64/local/open64//lib/gcc-lib/x86_64-open64-linux/4.2/32 hello.o -lopen64rt
这是使用opencc在Gentoo 32位系统上编译helloworld产生的输出。可以看到整个编译过程分为：使用gcc做预处理，使用cc142生成.spin文件，使用wgen42生成.B文件，使用inline生成.I文件，使用be生成.s文件，使用gcc生成.o文件。使用gcc生成a.out. 其中，预处理，生成.o和生成a.out都是使用未修改的gcc。 本文要介绍的是使用cc142生成.spin文件和使用wgen42生成.B文件。剩下的inline和be都是open64在做优化了。

cc142

cc142这个程序使用gcc的源码中直接生成的，open64在gcc的基础上做了修改。即，把gcc内部的AST树在转换为GIMPLE之前，转换成gspin表示。这是通过文件osprey-gcc-4.2.0/gcc/c-decl.c的finish_function()和c_write_global_declarations_1两个函数中，通过调用gspin()实现. 基本是把gcc AST树中的内容，识别转换输出到spin文件中。具体识别和对应的方法，参考文件gspin-gcc-interface.h。转换后的内容通过gspin_write函数写入spin文件中。
spin文件是二进制文件，不过你可以使用gspin42将其转换为文本格式。不过还是挺难看懂的。转换命令如下，该命令会生成文件hello.spin.txt。
gspin42 hello.spin

Wgen

接着wgen就读入该spin文件，并把它转换成WHIRL，即.B文件。整个转换在osprey/wgen/文件夹下进行。关键函数在wgen_expr.cxx中，变量和符号表，数据类型的转换在wgen_spin_symbol.cxx中。你可以使用ir_b2a，把.B文件转换为可读格式的。

如何Debug？

cc142中，对于gcc中的tree类型变量，gdb调试时，可以使用debug_tree()打印tree变量。gs_t，即gspin中的类型可以使用gs_dump来打印。
wgen中WHIRL用dump_wn和dump_tree即可。

这种架构的优点在于，把gcc和open64尽量分开。open64的gcc3.3前端，把open64的代码和gcc的完全整合在一起，因为gcc不断在升级，造成open64前端相对落后。采用gspin形式后，gcc前端升级，只要在libspin中，对于接口部分，增加gcc中新增的数据类型或者enum类型即可。之后再扩充后端支持。另外，这种形式也几乎可以让open64支持所有gcc支持到语言。兼容性更好。

题外话

为何不开发自己的前端？原因：投入巨大，而且没有必要。一个产品级的编译器，需要上千人年的时间才能完成。就是说要上千号人工作一年。LLVM从02年到现在，才勉强完成了C前端和后端，C++的前端还在努力中。所以不到万不得已，没有足够的人力和财力，没有哪个公司会专门投资做牛前端。单就Open64来说，因为和gcc一样都使用GPL协议，所以可以相互拷贝代码，相互兼容。更没必要重做前端。能在现有的基础上，扩充好gcc的前端，提高性能就行了。另外，下一个版本的Open64可能会移植4.5的gcc前端，拭目以待。

相关文章：

]]> http://www.lingcc.com/2010/08/23/11157/feed/ 2 Linux内存管理中的分页 http://www.lingcc.com/2010/08/22/11151/ http://www.lingcc.com/2010/08/22/11151/#comments Sun, 22 Aug 2010 05:47:04 +0000 erlv http://www.lingcc.com/?p=11151 相关文章：]]> 什么是分页

分页是操作系统中的内存管理机制。通过这种方式计算机可以为主存存取其他存储介质上的数据。在页存储管理机制中，OS从其他介质中得到相同大小的数据块，这种块即为页。

为什么分页

分页的蛀牙作用是可以让连续的地址空间存储在不连续的介质中。若不分页，操作系统需要把整个程序放到物理主存中连续的位置上，这会带来很多存储和碎片问题。分页是现代通用操作系统虚拟存储实现中的重要部分。它可以让OS使用磁盘存储RAM放不下的数据。

Linux中的分页

Linux使用swap描述在RAM和硬盘之间移动页，以及磁盘上用来存储页的区域。通常，使用一个磁盘分区做swap。2.6的内核已经支持直接使用文件来做swap。内核负责维护swap文件的位置，并直接访问硬盘。当有多个可供swap的磁盘空间时，Linux还支持优先级。当OS需要把某些内存页面swap时，会选择高优先级的设备。

性能问题

因为磁盘访问的延时比直接访问内存要高3到4个数量级。所以频繁的使用swap将大大降低性能。Linux提供了一个/prox/sys/vm/swappiness参数，可以通过它调整swap策略。

只需要简单的echo 0-100中的一个数值到这个文件中即可。值越大，系统swap到硬盘的越多。本博的笔记本默认是60。网上看到一个2.6内核维护者，将它设置成100。给出的理由：“我的观点是降低kernel swap出内存数据不对。你实际上不想让几百兆的内存在自己的机器内存中呆着，但从未被访问。所以把这些数据请到磁盘上，留出更多的主存给要用的程序”.

Page Fault

32位系统中，每个进程拥有的最大内存空间是4G，也整个操作系统能够识别的最大内存空间也是4G(除非使用high memory support)。因此Linux系统中程序访问某些页时，很可能这些页不在RAM中，如何找到这个页，并读取之，是分页系统的首要问题，即页缺失问题,Page fault。 操作系统接收到页缺失信号后，首先确定缺失的数据在硬盘中的位置，在RAM中获得一个空白页，以便存储数据，把需要的数据从硬盘装载到RAM内的页面中。更新页表，把控制权返回给程序，让程序可以重试导致页缺失的指令。内核所作的这一系列工作对程序都是透明的。

页大小

每个页能存储的数据多少，不同的系统会有不同。可以写个小程序判断页大小(如何得到当前linux系统的页大小)。页容量大，页缺失就少，减少不必要的内核动作。但这也有坏处，因为系统只能在一个页内通过分段来访问主存。若页太大，内存可用的页少，则势必浪费存储空间。通常的页大小为4KB-8KB.你可以通过修改内核头文件asm/param.h的EXEC_PAGESIZE,设置页大小。

参考：

相关文章：

]]> http://www.lingcc.com/2010/08/22/11151/feed/ 2 关于华为 http://www.lingcc.com/2010/08/21/11142/ http://www.lingcc.com/2010/08/21/11142/#comments Sat, 21 Aug 2010 10:25:34 +0000 erlv http://www.lingcc.com/?p=11142 相关文章：]]>
  • 华为的研发

    • 华为的研发体系总共有46000人，在全球有十几个研发机构。其中在国外的研发机构，本土化率达到80%。在国内，有北京研究所、上海研究所、南京研究所、西安研究所、成都研究所、杭州研究所、武汉研究所。侧重点各有不同，依次是数据通信和芯片、无线、业务软件、核心网、微波、公共平台、光网络。华为很注重知识产权保护，也就是专利的申请。

    华为研发工程师分为8级，新入职的都从0级开始。做到一定程度之后，就可以在管理岗和技术岗之间选一条路来走。二者都是末位淘汰制，其中管理岗每年淘汰10%，技术岗3%。

    华为现有80000人中，约有60000人持有公司股票。几乎全员持股。

    • 华为的产品和销售

    华为的产品全面覆盖IP网、固网和移动网。华为在这三个领域内都排在全球前三位。华为人比较称道的是，它是全球唯一一家产品覆盖所有通信领域，并在各个领域都排名前三的企业，并深信这将为华为日后的发展带来长足的动力。华为正在努力把IP网和移动网融合(FMC)

    华为从2000年开始，年销售额都保持30%以上的增长。这种持续的高速增长源于引入IBM的管理体系。2009年的销售额为260亿美元。

    • 华为应届生招聘策略变化

    这个现在还处于盛传阶段，但应该不会假。华为招聘的应届硕士研究生起新调整到8000，特牛的人可以谈到9000-10000.博士直接走特招。

    • 看华为

    华为人几乎每个都对华为的未来充满信心。加班确实不少，床垫只是用来睡午觉的。地下车库停的几乎清一色的小排量车，标志307，奇瑞A3，福特蒙迪欧，本田思域，看起来都还挺新的。看来发家的不多，不过收入应该都是中等水平，没有外面盛传的那么玄乎。随着竞争加剧，华为在以后的扩张中，肯定会遇到地方保护主义。核心技术，做别人做不了的东西，才能最终赢得市场。就象现在的Intel在全球卖芯片一样。这是华为加大知识产权保护的原因。另外，专利也是和竞争对手谈判的筹码。

    华为，是个靠自己打拼出来的公司。不像国字头的，有得天独厚的条件。也不像房地产，有剥削老百姓的资本。这确确实实令人佩服。祝华为越做越强！

    相关文章：

    ]]>     http://www.lingcc.com/2010/08/21/11142/feed/ 0