IT牛人博客聚合

上一篇 编译内存屏障（Compiler Memory Barrier）第一讲

1. gcc编译的大致过程

可以看到，gcc优化主要分两大部分:Tree优化和RTL(Register Transfer Language)优化；

前文所说的指令调度（Instruction scheduling）即为RTL优化的一部分。

2. 从RTL指令调度出发，追寻Compiler Memory Barrier的踪迹

还是从实验出发，实验代码如下：

volatile int ready;
int message[100];

void cmb (int i) {
message[i/10] = 42;
__asm__ __

查看全文: http://www.udpwork.com/item/6679.html

1. 编译优化导致编译器指令重排

要想理解Compiler Memory Barrier，先要理解Compiler Instruction Reorder，即编译器指令重排。

编译器指令重排是编译优化的结果，以gcc来说，它不知道为我们的代码默默做了多少事情，看看那整屏的优化选项就明了了。

本文以ubuntu下的gcc 4.4.3为实验，来逐步分析Compiler Memory Barrier的作用。

gcc的很多优化都可以造成指令重排，最常见的就是基本块重新排序（Basic block reordering）和指令调度（Instruction scheduling）。

为了解释Compiler Memory Barrie

查看全文: http://www.udpwork.com/item/6680.html

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: leveldb ubuntu 11.04下编译失败问题

我在最新的ubuntu11.04下编译leveldb的时候发现问题,但是在更早前的这个版本很正常：

yufeng@yufeng-laptop:/usr/src/leveldb$ make
g++ -c -DLEVELDB_PLATFORM_POSIX -I. -I./include -std=c++0x -g2 db/db_bench.cc -o db/db_bench.o
In file included from ./port/port.h:14:0,
from .

查看全文: http://www.udpwork.com/item/5082.html

一个很悲剧的事情是，上一篇文章中提到的toolchain，其实是用来编译内核的。真正应该用的是OpenWRT的SDK。所以先把OpenWRT的SDK搞下来。这个文章是事后所记，有点错漏在所难免。

$ svn co svn://svn.openwrt.org/openwrt/branches/8.09
$ make menuconfig
$ make

menuconfig的时候也用不着选太多的东西。记得把libpcap选上（M还是*随意），ruijieclient会用到相关的头文件和库。

把cross compiler所在的目录加入到PATH变量中。

$ export PATH=$PATH:/PATH/TO/YOUR/8.09

查看全文: http://www.udpwork.com/item/4536.html

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Systemtap的另类用法

通常我们在做内核编程的时候，会用到内核的数据结构，比如说textsearch提供了几种算法用于支付串查找。在用于正式的项目前，我们会希望考察下他的用法以及想体验下。最通常的做法是自己写个module,写个makefile,编译，运行，然后去dmesg里面看printk的结果。这个过程没啥问题，就是太罗嗦。好了，现在我们有更方便的方法了：systemtap.

Systemtap是个脚本，先翻译成c kernel模块代码，然后编译，插入到内核运行，同时提供最基本的内核和应用模块的通讯管道，在应用模块这里收集信息。 它还支持guru模

查看全文: http://www.udpwork.com/item/3365.html

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: 如何在TILEPro64多核心板卡上编译和运行Erlang

参考文章：

1. https://groups.google.com/group/erlang-programming/msg/2d61b1083a10a7b6

2. http://erlang.2086793.n4.nabble.com/How-to-Cross-compile-Erlang-OTP-R13B04-for-TileraPro64-td2119304.html

美国Tilera公司的众核服务器，单颗内核包含64颗CPU。硬件架构图：

卡长这样的：

Erlang已经可以在这款C

查看全文: http://www.udpwork.com/item/3235.html

vimers都说emacs慢，Eclipse, Visual Studio, Netbeans笑而不语。
-- 佚名

背景

前些日子，微软宣布Visual studio 2010的EMACS扩展。此前，Visual studio 2005 6.01已然引入了Emacs的键盘模拟，这次又将Visual studio 的Emacs化更进一步，这种事发生在Microsoft这样无利不起早的企业,原因呢,你懂得。

话说，武功再高，也怕菜刀。Emacs玩的再溜，也保不齐哪天你要去开发Visual studio 程序。习惯了Emacs的高效，使用Visual studio

查看全文: http://www.udpwork.com/item/2754.html

换了一台新机器去做TPM硬件驱动的开发，于是从远程仓库把代码clone下来。试着把代码编译一次，出问题了，满版的错误，费点时间看了一下，其实是stddef.h没有找到造成的。

新机器和原来的机器都是一样系统，工具链也是一样的，代码也已经在我原来的机器上编译通过了。用find找了一下stddef.h，在机器上也是有的。仔细对比了一下通过和不通过的CFLAGS，发现不通过的情况下，头文件路径中没有gcc的包含路径，问题就出在这里了。

再看Makefile，gcc路径是通过如下的方法取得的。

GCC_INSTALL = $(shell gcc --print-serarch-dirs | sed -n -e 's/inst

查看全文: http://www.udpwork.com/item/1760.html