编译点滴 » 开源

淘宝code上线，局外人高兴一下

erlv — Wed, 30 Jun 2010 08:37:03 +0000

咱国内IT公司也有支持开源项目的平台了！淘宝开源平台正式上线。淘宝是家让人敬佩的国内IT公司，知道吸引开发者的公司才会有持久的技术创新力！

淘宝code访问地址： http://code.taobao.org/

刚刚试着创建了一个项目，很不错。整个界面干净整洁，主要功能一览无余。界面是英文的，估计是考虑到通用性。默认使用SVN管理代码，有trac可以跟踪bug和项目进度。不过偶尔会出现页面无法加载的问题。而且有些动态更新的内容，加载比较慢。

另外，点击某个网页会出现中文，呵呵。可见淘宝code肯定会推出中文界面。期待！

咱国内的IT公司很有希望！为之高兴。某些大公司，也别只顾着赚钱。比如腾讯，比如人人，比如新浪，比如搜狗。国内的人才每年一拨一拨的，都被外企拉去做苦工。。。。。

龙芯N32系统上的Squirrelfish性能

erlv — Mon, 28 Jun 2010 08:58:37 +0000

缘起：写这篇文章因为报名参加了龙芯开源软件大赛，项目是《Webkit-龙》,把webkit移植到龙芯N32系统上，起初是想做chromium的移植。但在起步的过程中，发现一是Google的V8引擎，对mips的支持基本处于不可用状态，而且chromium为了追求性能，使用的方式太过灵巧，如Native client(Google的野心–Native Client+LLVM),凭自己的一己之力，靠业余时间，很难完成，只好先做webkit了。

Squirrelfish 是Webkit的Javascript引擎。针对龙芯平台(MIPS)已经有了JIT支持，但仅仅对O32系统才有，本博曾经介绍过相关内容（WebKit和Firefox的JavaScript性能对比）。

切入正题，N32系统下，龙芯平台上，Sunspider性能测试结果如下：
============================================ RESULTS (means and 95% confidence intervals) -------------------------------------------- Total: 9125.6ms +/- 0.1% -------------------------------------------- 3d: 1058.6ms +/- 0.2% cube: 326.9ms +/- 0.1% morph: 380.9ms +/- 0.6% raytrace: 350.8ms +/- 0.1% access: 1441.2ms +/- 0.1% binary-trees: 108.4ms +/- 0.3% fannkuch: 829.2ms +/- 0.2% nbody: 249.0ms +/- 0.0% nsieve: 254.6ms +/- 0.4% bitops: 1088.6ms +/- 0.2% 3bit-bits-in-byte: 196.2ms +/- 0.3% bits-in-byte: 250.1ms +/- 0.2% bitwise-and: 224.9ms +/- 0.3% nsieve-bits: 417.4ms +/- 0.3% controlflow: 138.2ms +/- 0.2% recursive: 138.2ms +/- 0.2% crypto: 621.5ms +/- 0.1% aes: 323.0ms +/- 0.1% md5: 145.3ms +/- 0.2% sha1: 153.2ms +/- 0.3% date: 523.6ms +/- 0.6% format-tofte: 302.4ms +/- 0.6% format-xparb: 221.2ms +/- 1.3% math: 931.3ms +/- 0.1% cordic: 356.0ms +/- 0.2% partial-sums: 324.5ms +/- 0.1% spectral-norm: 250.8ms +/- 0.2% regexp: 1681.6ms +/- 0.1% dna: 1681.6ms +/- 0.1% string: 1641.0ms +/- 0.2% base64: 232.9ms +/- 0.2% fasta: 261.9ms +/- 0.2% tagcloud: 394.9ms +/- 0.2% unpack-code: 525.2ms +/- 0.2% validate-input: 226.1ms +/- 0.7%

与O32系统的性能相比：9125ms vs 6355ms，慢了一半。一个原因是N32现在没有JIT支持。

正确性方面，使用webkit的 Javascript测试集测试。有7个例子出错：
ecma/Date/15.9.5.14.js ecma/Date/15.9.5.28-1.js ecma/Date/15.9.5.29-1.js ecma/Date/15.9.5.31-1.js ecma/Date/15.9.5.34-1.js ecma/Date/15.9.5.35-1.js ecma/Math/15.8.2.17.js

WebKit-龙项目方面：

主要优化JavaScript引擎，
现在WebKit虽然能编译，但运行还会报错：

Can't find built framework at "/root/WebKit/WebKitBuild/Release/lib/libQtWebKit.so".

这个项目刚刚启动，欢迎加入

前瞻-主流处理器中的数据并行支持(SIMD)

erlv — Tue, 04 May 2010 12:46:15 +0000

引言部分：

多媒体处理算法应用在很多媒体处理环境中，如对文本，手写数据，2D/3D图形和音频对象的捕捉、制造、存储和传输等。过去都是使用昂贵的多媒体处理硬件协同工作来加速。现在，通用处理器通过在体系结构上增加媒体处理支持来减少使用协同处理器分配和返回带来的开销。在通用处理器上一个基本的操作能同时作用多个元素的支持成为SIMD并行处理。通过SIMD扩展，通用护理器通过捕捉多媒体算法中潜在的并行特性来加速应用。

自 Intel在Pentium II和Pentium 处理器引入了MMX技术以来，IA-32架构已经引入了许多SIMD扩展，分别是：MMX，流SIMD扩展(SSE), 流SIMD扩展(SSE2)和流SIMD扩展(SSE3)，SSSE3，SSE4和高级向量扩展(AVX).这些扩展都提供了一组指令，能够为封装好的整点或浮点数据提供SIMD类型的操作。其他结构也有自己的SIMD扩展。如AMD的3DNow！，Cell和PowerPC的AltiVec等等。
可惜的是，和CPU提供的其他技术一样，多媒体指令系统扩展的潜能并没有完全的发挥出来。目前，已经有一些论文在倡导科学家，软件开发人员使用这些指令加速程序。
这篇评论试图更深入的介绍 Intel的SIMD扩展，回顾努力使用这些扩展的一些研究，讨论阻碍多媒体扩展广泛应用的问题，并试图给出一些针对行的解决方法，和潜在的性能提升点。

SIMD 技术：

SIMD是最早提出的并行处理模式之一，也是最简单最普遍的并行方法，试图用一个指令对数据集合中的每个数据作相同的操作。如下图所示：

单指令流多数据流模型

虽然SIMD技术还没有广泛应用，但也没有完全小时。因为SIMD扩展对于特定的应用仍然很有意义，这些应用的特点是本身有并行的任务，需要大量的独立数据运算，包括3D图形运算，图像处理，语音识别，科学计算，数据库查询等。

MMX技术：

MMX是在第五代奔腾处理器中作为附加扩展引入的，最早用在提升图像生成，加密，视频编解码和I/O处理上，相对于无MMX技术的处理器，通常能带来1.5到2倍的加速.MMX能处理64位封装的整型，引入了8个64位寄存器来实现、四种MMX数据类型(封装的字节，半字，字，双字）和57条MMX指令.
8个MMX寄存器是通用寄存器，是浮点寄存器(ST0-ST7)的低64位的重用.MMX的数据类型可以是8个字节整型元素的数组，4个半字整型元素的数组，2个字整型元素的数组或者1个双字整数.做SIMD运算时，SIMD指令取两个MMX寄存器中的操作数，作相应的SIMD运算，并将结果存入结果寄存器中。MMX的指令系统由57条指令构成.包括基本算术操作、比较操作、转换操作、逻辑操作、移位操作、访存及寄存器间移动操作和状态指令。因为MMX寄存器复用浮点寄存器，必要时，需要对MMX寄存器清空以便正常的浮点运算可以进行。
MMX 引入了一种新的溢出方式：饱和溢出(Saturation overflow).传统的溢出很多都是反转溢出(wraparound overflow).对于反转溢出，即溢出高位。但对于图像处理，这样做就不合适，比如两个白色的像素点相加，因为溢出，取低位，可能会是一个黑色的点，显然和实际不符。饱和移除就是为解决这个问题，即若溢出则保留最值，而不是简单的取最低的几位。MMX提供有符号和无符号两种饱和溢出。

流 SIMD扩展技术(SSE)

SSE在Intel 奔腾III中引入，作MMX技术的升级，并保持向后兼容。SSE扩展包括增加对128位寄存器內封装的或者普通的单精度浮点值的操作。SSE扩展引入了一个新数据类型：128位封装单精度浮点类型，有4个IEEE标准的32位单精度浮点类型组成.该单精度数可以在XMM寄存器內或者主存中。SSE引入5类新寄存器：XMM寄存器：8个128位寄存器支持单精度运算(XMM0-XMM7),能被x87 FPU，MMX寄存器或通用寄存器访问；MXCSR寄存器：32位寄存器包含SIMD浮点操作的控制和状态信息；MMX寄存器：用于64位封装整型，或者为某些在MMX和XMM寄存器之间运算的操作提供操作数；通用寄存器：因为MMX和XMM寄存器不能用于存地址，8个32位的通用寄存器就被引入用于保存 SSE模式下的操作数的存储地址；EFLAGS寄存器：用于记录某些比较结果的32位寄存器.
SSE也引入了70条新指令，可以分为4 类：SIMD单精度浮点运算；MXCSR状态管理指令；64位SIMD整点指令(扩展原MMX指令集);cache控制，预取和取值指令。
目前很多的图形软件采用了这项技术，如Adobe Photoshop会在有SSE扩展的机器上用SSE加速，微软也在DirectX 6.1和之后的音/视频驱动中加入了SSE，这些都已经包含在Windows 98,Me,2000,NT和XP。

流SIMD扩展技术 2(SSE2)

SSE2在奔四和Xeon处理器中引入，SSE2允许更多的计算并行，并扩展了MMX和SSE中的指令，而且引入了两个双精度浮点数据类型。具体引入特性如下：六中数据类型、支持新数据类型的指令和对已有SIMD整型操作的扩展、修改已有指令以便支持SSE2.
双精度 SIMD运算的支持增强了在XMM寄存器上作高精度计算的能力。SSE2也让XMM寄存器可以作128封装整型的运算。现在程序员可以使用完备的SIMD 寄存器、数据类型和指令来开发混合单/双精度浮点，64位/128位整点的数据.SSE2并没有引入新的寄存器，只是做了功能扩展。

流 SIMD扩展技术3(SSE3,SSSE3)

SSE3在奔腾四为了支持超线程而引入。SSE3扩展包括13条新指令.SSE3并没有引入新的数据类型和寄存器.

SSSE3在Intel Core架构中引入，增加了16条指令，每条指令都能在64位的MMX寄存器或128位的XMMS寄存器上运算

流 SIMD扩展技术4(SSE4)

SSE4 2006年9月发布，AMD k10和Intel Core中有使用，包括54条新指令。SSE4中增加了并非特定于多媒体应用的指令，如STTNI指令可以加速文本和字符串处理；ATA能加速冗余校验。

流 SIMD扩展技5(SSE5)

SSE5是AMD 2007年8月发布的，作为AMD64结构在128 SSE基础上的补充。

高级向量扩展 (AVX)

Intel 2008年3月发布的SIMD扩展.寄存器从128位扩展为256位，并使用新的寄存器名YMM0-YMM15，已有的128位指令使用256位寄存器的低128位.使用无副作用指令格式，即所有形如a=a+b的操作都会会被替换为c=a+b，这样操作数计算的结构不会污染原操作数，所有的有两个操作数的 XMM指令都会用这种方式扩展为3个操作数的形式.访存中对SIMD数据对齐的要求放宽。
AVX中指令的编码方式也有改变，通过修改前缀使得无副作用指令格式得意实现。AVX扩展适用于多媒体、科学计算和经济方面的应用，能有效增加并行性和浮点SIMD运算的吞吐率，降低寄存器载入开销。目前Linux 2.6.30、Windows 7 SP1和Windows Server 2008 R2 SP1都有AVX增强.

3DNow!技术

3DNow！是AMD在MMX的基础上作的扩展，和SSE对MMX的扩展相似。最早用在 AMD-K6-2处理器上，之后在AMD-K6-III和AMD Athlon处理器上实现。3DNow！是一组指令，有效缓解了传统多浮点运算和多媒体应用的瓶颈。3DNow！使用MMX寄存器但增加了45条浮点指令，能同时对1个或2个单精度浮点值作运算.3DNow！支持加、减、乘、除、和整点之间的转换、比较、绝对值、数据预取等操作。根据AMD提供的资料，3DNow！的带来，如同SSE为MMX带来的同等提升，但指令和复杂度降低。但SSE和3DNow！不兼容。目前微软的Windows 9X，NT和所有最新系统，DirectX 6.x可以使用3DNow！加速，OpenGL也可以使用3DNow！加速.
3DNow！为高分辨率的显示提高了帧频率，更接近现场的高保真音频等等。

小小结：

操作系统对某个体系结构的支持，已经远远不是单纯的某个指令集能解决的问题。为了用户体验和应用性能提升，需要更多的软/硬件协同的设计。软件设计中需要哪条指令更高效的运行，哪些指令用不到，都可以给硬件设计作参考。这也是Wintel联盟如此紧密的原因。与CPU架构密切相关的SIMD指令，作为改进普通中端用户多媒体体验的关键，更是在Windows系统中占据不可替代的作用。

在Gentoo portage中做了个简单的调研，发现现在使用SIMD加速的包很少，如mplayer，ffmpeg，gimp，大多数都为多媒体应用程序，支持最多的也只有sse，sse2,3DNow和mmx，再新的根本没有。而且Intel等芯片设计厂商也有一些未公开的特殊指令，只提供给某些合作伙伴使用，再加上开源爱好者们没有那么多的时间和精力去根据已有的程序和算法，按照某个芯片独特的SIMD支持，设计并验证针对它的软件修改。那很多开源软都难用到这些特性。性能也就没办法和Windows下的相比。

这小小结，只是愤青的一点感慨而已。既得利益集团是不会在乎这些的。

敬请期待SIMD系列下文《前瞻-拿起SIMD的武器!》

PS：原文根据ayaya的评论做了很多更正，谢谢ayaya：）

参考：
A Review of SIMD Multimedia Extensions and their Usage in Scientific and Engineering Applications.

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

http://en.wikipedia.org/wiki/SSSE3

http://en.wikipedia.org/wiki/SSE4

http://en.wikipedia.org/wiki/SSE5

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

http://en.wikipedia.org/wiki/CVT16_instruction_set

如果SourceForge.net沦为政治工具？

erlv — Tue, 26 Jan 2010 00:55:03 +0000

刚开电脑就看到一条新闻，souceforge在古巴，伊朗，朝鲜，叙利亚，苏丹不能访问，被屏蔽了。这些都是与美国为敌的国家。服务器在别人的手里，不管你打着多么大公无私的旗号，多么贡献开源，人家看你不爽，一拔网线，你就啥都干不了。
每个喜欢互联网技术，拥护开源的人都不想让开源沦为政治工具，但这是一个政治主导的世界，你得听政府的，政府是老大，你在政府的地盘上混，管你什么道义，什么自由，什么开源，统统只是工具。
我不是在鼓吹网络长城多么利国利民，但我们确实需要一种手段，让我们与国外能自由交流的同时，能摆脱对他们的依赖。正如现在国内，开源爱好者们都很乐于将自己的代码贡献出来，给开源社区，但当它变成政治工具的时候，我们如何取得该属于我们的权利？
SourceForge.net好像在国内还没有官方的镜像服务器. 如果我们的官老爷们真的为我国的信息产业处心积虑，鞠躬尽瘁的话，倒不如拿支持防火长城项目1%的钱，作为政府鼎力支持，在国内建几个开源镜像服务器，这样，至少我们还能有所有的源码，至少我们有了独立自主！

WebKit和Firefox的JavaScript性能对比

erlv — Fri, 22 Jan 2010 14:37:22 +0000

严格的说WebKit仅仅是个浏览器核心，采用该核心的浏览器很多，如国内的搜狗浏览器，遨游浏览器。其他的如google的chrome(Windows平台，linux平台下为chromium),epiphany(linux平台下，gnome2.28版本之后),苹果的Safari 都采用了webkit的内核。Firefox则是采用Gecko的内核，这是NetScape公司开发的内核，后来开源，mozilla继续开发。另外，现在还有另外两种常见的浏览器内核，Trident主要用在IE系列上，Presto主要用在Opera上。

这篇文章仅仅针对浏览器处理JavaScript的性能作比较，主要在X86平台和龙芯平台。先来解释一下JavaScript，JavaScript是互联网内较为常用的脚本语言，面向对象，主要在浏览器内解释执行，用于生成动态网页，因为很多语言特性受Java影响，所以叫JavaScript。通过JavaScript，浏览器可以运行服务器想要在访问者终端上运行的一些计算程序，以达到更好的浏览体验。

再说说浏览器内核和JavaScript的关系，其实JavaScrip脚本的执行仅仅是浏览器内核的一部分，其他的还有Html语言的解释执行，网页的呈现等等也是内核要做的。之所以这么关心浏览器核心对JavaScript脚本的处理情况，是因为现在的很多应用不再是简单的网页浏览，如gmail，google reader，gooe wave还有一些网页3D特效等等都需要在客户机上作计算，这就需要JavaScript大显身手了。而且越来越多的应用依赖JavaScript，所以现在浏览器对JavaScript的处理速度直接影响着用户体验。目前WebKit的JavaScript引擎SquirrelFish，JavaScript的引擎是SpiderMonkey

目前JavaScript在大多数平台上的处理是靠解释执行的，又因为是动态类型，面向对象。。。，决定了JavaScript执行效率低，所以就诞生了各种针对JavaScript的优化，也有了测试JavaScipt解释器性能的BenchMark，目前常用的是Sunspider和google V8，这篇文章中的对比针对Sunspider测试集。

另外还要说说JIT，Just In time，转换，将部分程序代码直接转换成机器码执行，这种技术在运行时优化中比较常用，JavaScript是解释器，所以JIT在解释器中也是很重要的优化手段。目前X86的webkit和Firefox默认就有JIT支持，但龙芯平台上还没有，本博也是最早对龙芯2F平台有JIT支持的Webkit和firefox JavaScript引擎作对比的，目前这两个JIT都还没有进入官方的代码库中，感兴趣的朋友可以在下面的前两个链接中找到相关源码。其中webkit的补丁还要做些宏的修改，改动不大。这两个都是从官方源码库checkout出来并修改之后的。其中firefox的JIT部分是由ZSC大牛写出来的，详细的讨论贴和测试结果可以在龙芯论坛看到，见下面的第三个链接。
x86下epiphany(webkit内核)和firefox开了jit之后的性能，如下

webkit Total:                  833.6ms +/- 2.1%
firefox Total:                 1774.4ms +/- 2.7%

（测试环境是我的笔记本 intel Pentium t2390,开了频率调节，所以波动较大)、两个差距：

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.13x as fast     1774.4ms +/- 2.7%   833.6ms +/- 2.1%     significant

=============================================================================

  3d:                  2.96x as fast      257.2ms +/- 2.1%    87.0ms +/- 1.0%     significant
    cube:              3.36x as fast       79.2ms +/- 1.7%    23.6ms +/- 2.9%     significant
    morph:             1.52x as fast       50.4ms +/- 1.4%    33.2ms +/- 3.1%     significant
    raytrace:          4.23x as fast      127.6ms +/- 3.0%    30.2ms +/- 3.4%     significant

  access:              3.26x as fast      237.0ms +/- 4.7%    72.8ms +/- 2.8%     significant
    binary-trees:      8.82x as fast       67.0ms +/- 4.4%     7.6ms +/- 9.0%     significant
    fannkuch:          3.48x as fast       98.2ms +/- 0.6%    28.2ms +/- 3.7%     significant
    nbody:             2.50x as fast       51.4ms +/- 10.3%    20.6ms +/- 3.3%     significant
    nsieve:            -                   20.4ms +/- 56.6%    16.4ms +/- 4.2% 

  bitops:              1.42x as fast       53.8ms +/- 1.9%    38.0ms +/- 0.0%     significant
    3bit-bits-in-byte: *3.10x as slow*      2.0ms +/- 0.0%     6.2ms +/- 9.0%     significant
    bits-in-byte:      -                   11.0ms +/- 8.0%    10.4ms +/- 6.5%
    bitwise-and:       *2.33x as slow*      3.0ms +/- 0.0%     7.0ms +/- 0.0%     significant
    nsieve-bits:       2.62x as fast       37.8ms +/- 1.5%    14.4ms +/- 4.7%     significant

  controlflow:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant
    recursive:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant

  crypto:              2.34x as fast       93.8ms +/- 1.7%    40.0ms +/- 2.2%     significant
    aes:               2.57x as fast       54.0ms +/- 3.6%    21.0ms +/- 4.2%     significant
    md5:               2.62x as fast       26.2ms +/- 2.1%    10.0ms +/- 0.0%     significant
    sha1:              1.51x as fast       13.6ms +/- 5.0%     9.0ms +/- 0.0%     significant

  date:                1.87x as fast      275.2ms +/- 2.0%   147.0ms +/- 1.0%     significant
    format-tofte:      2.75x as fast      149.0ms +/- 1.0%    54.2ms +/- 1.0%     significant
    format-xparb:      1.36x as fast      126.2ms +/- 4.0%    92.8ms +/- 1.7%     significant

  math:                1.12x as fast       89.8ms +/- 1.8%    80.2ms +/- 21.7%     significant
    cordic:            2.13x as fast       43.4ms +/- 3.3%    20.4ms +/- 9.2%     significant
    partial-sums:      *1.41x as slow*     34.4ms +/- 2.0%    48.6ms +/- 38.2%     significant
    spectral-norm:     1.07x as fast       12.0ms +/- 0.0%    11.2ms +/- 12.2%     significant

  regexp:              3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant
    dna:               3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant

  string:              1.80x as fast      591.4ms +/- 3.3%   329.2ms +/- 1.6%     significant
    base64:            *1.24x as slow*     28.4ms +/- 2.4%    35.2ms +/- 1.6%     significant
    fasta:             1.71x as fast      133.0ms +/- 2.3%    78.0ms +/- 4.6%     significant
    tagcloud:          2.81x as fast      169.4ms +/- 3.8%    60.2ms +/- 8.2%     significant
    unpack-code:       1.91x as fast      193.8ms +/- 4.4%   101.6ms +/- 2.7%     significant
    validate-input:    1.23x as fast       66.8ms +/- 5.8%    54.2ms +/- 6.4%     significant

龙芯上的JIT具体对比数据不便透漏，可以从下面第三个链接中找到第一版发布时的测试数据。这里仅仅给出一个对比。webkit之所以with GUI是使用编译出的迷你小浏览器中测试结果，no GUI是使用测试脚本跑出来的结果。

 Webkit with GUI Total:                  6723.4ms +/- 0.5%
        no GUI   Total:                  6355.8ms +/- 0.5%
 Firfox Total 7000 ms 左右。

注：龙芯中的JIT现在还不够成熟，其中Webkit的JIT仅是针对MIPS III做的，没有针对龙芯的特殊优化。

另外，X86中firefox的版本是3.5.7，龙芯中firefox的版本是3.7pre1.WebKit在X86中版本是epiphany的2.28中的版本，龙芯中为SVN中的2010-01-12 r53114。X86运行环境为Gentoo，Gcc4.4.2,Glibc2.11,龙芯运行环境是玲珑一体机，GCC4.3(龙梦修改版）,Glibc2.10。

对比结果可见：X86中WebKit浏览器的性能要明显优于Firefox，达到两倍之多。龙芯相比起来还有些差距，不过相信优化后龙芯的性能会更好。

参考

https://bugs.webkit.org/show_bug.cgi?id=30144

http://dev.lemote.com/code/firefox-3.7-loongson-jit

http://lemote.com/bbs/viewthread.php?tid=26687&extra=page%3D1

http://en.wikipedia.org/wiki/Google_Chrome

http://ineolee.com/pc/several-browser-core-introduction/

用crossdev装龙芯的n32 gnu交叉工具链

erlv — Tue, 05 Jan 2010 13:51:08 +0000

不管怎样，龙芯是咱们应该骄傲的，但是用它来编译东西确实很慢，我们很需要一个交叉编译器，能够在性能稍好的平台上为龙芯平台编译程序，x86是目前比较常见的平台，本博在实际工作中，需要在gentoo系统上安装支持龙芯n32的交叉编译器，下面分享一下本博的安装过程。
crossdev是gentoo系统下很方便的交叉编译环境安装和卸载工具，想进一步了解可以参考本博的这篇文章Gentoo中的交叉编译利器–crossdev，这里只讨论有了crossdev之后的安装过程。
首先，我们需要支持n32的gcc,glibc，linux-header,insight和binutils.其中，gcc,gdb,insight和linux-header都已经有了官方支持，我们还需要glibc的一些patch。头疼打patch这种繁重的劳动？别急，已经有国内的开源爱好者们做好了这些，我们仅仅需要几个附加步骤即可。

我们需要首先有gentoo的龙芯overlay，这个overlay是gentoo开发者zhllg维护的龙芯gentoo n32系统的overlay，因为我们需要n32的glibc，所以就需要这个overlay。虽然你可以直接只下载glibc的相关文件，但是推荐你直接clone整个overlay，这样的话，以后你就可以直接用git工具和zhllg的overlay更新了。如果不懂什么是overlay，可以参考这个链接Gentoo Overlays: Users’ Guide。你需要一个位置存放overlay的内容，因为我们只需要glibc，所以你最好放在/usr/local/portage/以外的地方，然后在/usr/local/portage/做glibc的链接到龙芯的overlay里，这样能避免安装其他软件中的龙芯支持，搞乱你自己的x86系统。假定你在/root下存放overlay。你需要执行以下命令:cd /root git clone git://www.gentoo-cn.org/var/git/loongson.git cd /usr/local/portage/ mkdir loongson cd loongson ln -s /root/loongson-overlay/sys-libs/ sys-libs ##glibc指向overlay中的glibc ln -s /root/loongson-overlay/sys-devel/ sys-devel ##将gcc指向overlay中的gcc
至于为啥要把gcc也做软链接到龙芯的overlay，其实是因为历史遗留问题，原来的gcc4不支持，需要打补丁，现在不需要了，不过以后可能还需要，所以就做了这个软链接，不过你到overlay里，ls -l一下可以看到其实overlay里gcc也是链接，指向/usr/portage/下的gcc。

接下来就要告诉emerge，从overlay中找工具链中的gcc/binutils/glibc。我们要编辑/etc/make.conf文件，添加本地龙芯的portage，这里要注意，之所以我在/usr/local/portage下又创建文件夹是因为我有layman。另外你需要确保/usr/local/portage/loongson在你所有overlay查找的最前面：PORTDIR_OVERLAY="/usr/local/portage/loongson $PORTDIR_OVERLAY"
这样做是为了确保使用龙芯overlay中的gcc和binutils。

接下来就能直接安装了：crossdev -t mips64el-unknown-linux-gnu

之后你就能享受交叉编译了，mipsel-unknown-linux-gnu-gcc 编译个helloword试试吧:)

龙芯是咱们自己的东西，大家一起努力才能让龙芯走向世界！

这里要注意几个问题：
1，如果你是新安装的glibc，龙芯overlay中的glibc是2.10的，你gentoo系统的glibc的版本不能比这个低才行，不然会有冲突，具体的错误提示我忘记了。
2，一定要让龙芯overlay在PORTDIR_OVERLAY的最前面。
3，具体安装以下内容
linux-headers-2.6.27-r2 from portage.
binutils-2.19.1-r1 from loongson overlay.
gcc-4.4.2 from portage. The gcc in loongson overlay currently is just a symlink to portage gcc.
glibc-2.10.1 from loongson overlay.

参考

http://r0bertz.blogspot.com.sixxs.org/2009/11/update-on-building-mips64el-cross.html

十年改变我们的那些技术

erlv — Wed, 30 Dec 2009 13:25:46 +0000

还有一周，公元记年的最后一位又要从0开始了。回首这十年，互联网技术的发展令人震惊。是时候总结以下这十年了，那些改变我们生活的技术和不怎么有用的技术们了。原作者通过邀请O‘Reilly内部的编辑，作者和朋友们，以及一些工业界的人士，连同一些评论和趋势，为我们总结了分别十种十年来最好和最坏的技术，这些技术没有特定的顺序。

AJAX–已经很难记起AJAX(Asynchronous JavaScript and XML)诞生之前的生活时什么样子了吧，没关系，我将带你回忆。那是非常枯燥的年代，Web 1.0包含了大量的静态网页，每次点击都需要在web服务器上处理一个轮回，若你需要更多内容，就必须在网页中嵌入JAVA工具，并在心中祈祷用户的浏览器支持它。没有AJAX，我们就不会走到Web2.0,GMail和很多基于云计算的web应用。Flash依然很流行，但是在HTML5将要到来的时候，以前需要Flash或者Silverlight才能运行的RIA(胖互联网应用，Rich Internet Application)现在都能使用AJAX完成了。
Twitter(咱们国内应该叫微博)–一开始的时候，博客(blog)就想它的名字一样，只是一个网页记录(web log).换句话说，就是一个作者自己办的网站杂志。如今，博客已经演化成胡言乱语，发表见解论文和所有作者想法的一个平台。这时候Twitter出现了。当然，人们想要知道某个名人晚饭吃了什么，最有用的微博是一个小的URL地址加上一小段评论，然后把这些信息实时的粗汉地出去，通知每个人关于现在发生的新闻，或者某个角落的餐馆里的奇闻轶事。这也是为什么Twitter容易成为该领域的引领者。
WIFI的普及–我想让你想想一下90年代中期你在路上的情景，你走进一个酒店，在房间里拿出笔记本电脑，然后找到你的RJ-11电缆，检测房间的电话是否支持音频拨号(通常不支持).然后，你查找本地的电话号码，找到当地ISP，在你的笔记本上拨号，于是，你有了一个能收发email的56k的网络。而现在，WIFI到处都是，你甚至不用付钱，就能随时随地的连接高速网络，从本地的麦当劳到你的宾馆房间到机场。当然，没有底层的支持是不可能的，自从不安全的WIFI接入点导致了很多头疼的安全问题，而且除非你的杀毒软件是最新的，否则开放的接入点也有头痛的安全问题，不管怎样，WIFI的普及已经能让我们的世界更加的互联。
电话更智能–在90年代默契，我们有了第一部数字移动电话，但是PDA和手机联姻得到的智能手机还是用了十年的时间才降生。Palm和Treos合作，生意越做越大，同时Windows Mobile系统也开始出现。RIM的黑莓将更多的商务功能装进手机，但是貌似现在iphone抢来了接力棒大步向前冲。你可能还不确定Android是不是比3GS和Pre更好，但是不可否认，IPhone凭借App Store的商业模式，做了智能手机的第一把交椅。现在看来下一个融合点是上网本，因为更多的上网本有了3G接入功能，接下来，VoIP Skype将到来并走向商业应用。
极客文化–DIY仿佛永远让人发烧。从Ham radio到摄影到铁路建模。这个十年仿佛将每个人的积极性调动了起来，最早是从无线电发烧友们开始的。Arduino使得每个人都能将控制功能嵌入任何设备，而业余PCB爱好者则更是将爱好从杂乱无章的厨房应用，到收购点击-上传设计，甚至一个能打印3D人物模型的打印机。工业界也对这些极客们束手无策。虽然电子产品越来越复杂使得大多数人改造他们越来越没有勇气，但实际上极客们已经能将一台电脑变成任何一种你能想象出的设备，然后重新编程完成更多的事情。不喜欢你数码相机上的软件？那就安装你自己的吧，只要把DVN安装到你的linux系统里。同时，Mythbusters和Maker Faire事件也说明，只要有巨大的市场，硬件hack也能吸引很多的眼球。
开源变成主流--你能快速说出5中开源软件吗？但是1999年，这可能很难做到。现在，Firefox已经很易用，Open Office,Chrome,Audacity,Eclipse(若你是个开发者)。Blender,VLC还有很多。很多上网本都是用linux作为默认系统。正如Gandhi所说：“他们先躲避你，接着嘲笑你，接着打击你，然后你就赢了”,当微软发布开源代码的时候，我们知道我们已经在从打击走向胜利的路上了。
更多的资源–56k的猫，20M硬盘，640K内存，2Mhz处理器。这些你都不需要走进博物馆作为艺术品看到。当然，你现在有了更好的体验。摩尔定律已经引领技术创新很多年，现在貌似存储和带宽变成了平静。我的Iphone的硬盘是我第一台电脑的3200倍，我Mac电脑上的显存是我第一台电脑的16000倍。我们现在都能使用我们的手机作比十年前在我们的PC上还要惊艳的事情。

最坏的几种技术没有翻译，窃以为和我们关系不大。

原稿来自O‘Relly： http://radar.oreilly.com/2009/12/the-best-and-the-worst-tech-of.html

拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)

erlv — Thu, 24 Dec 2009 02:44:43 +0000

啥是nanojit？

Javascript的JIT后端，原先firefox直接使用javascript解释器，效率比较低。nanojit可以将频繁执行的javascript代码直接翻译为机器码执行，效率更高，性能更好。详细的介绍可以参看这篇文章：an overview of TraceMonkey， (我是中国人，我要看中文 ).本博还有一篇英文介绍，自己的蹩脚英语拙作。确实闲着无聊可以猛击这里。

咋又蹦出来个tracemonkey？

这得先从spidermonkey说起，spidermonkey是firefox里的Javascprit解释器。因为增加了Nanojit，这种通过跟踪(trace)热JAVAscript代码的JIT。所以改名叫tracemonkey。

我只关心这个firefox！

那就从这个地址下载吧，firefox_release.mips1-1_mipsel.deb. 下载之后切换到root帐号或者直接执行。注意目前Nanojit只测试了O32的龙芯，龙芯默认的操作系统和其他Debian衍生系统都能使用(目前测试了debian-en和Rays,没有问题).目前2E和2F的机器都能使用。N32的gentoo系统还不支持。
sudo dpkg -i firefox_release.mips1-1_mipsel.deb

然后执行firefox命令就行了(若su 切换到root安装且遇到No display specified 错，你可能需要先退出root账户).

安装的这个firefox是基于mozilla-central中最新的3.7a1pre修改而来，虽然在测试中，没发现firefox本身很多bug，但不排除这种可能性。所以用之前您得心里有底 : )

注意，两个不同版本的firefox不能同时运行。你如果想测试性能的话，需要先关掉，再启动另一个。

这个命令都在我可爱的龙芯电脑上做了啥？

呵呵，别紧张，它只是在/usr/local下安装了支持Nanojit的firefox，修改的文件夹有share，bin ，lib和include。你原来的firefix还在。安装了之后默认会启动新安装的这个firefox。如果你仍然想换回原来的，可以修改PATH中的搜索次序。

给我个理由先，为啥要装它

一句话概括，执行javascript时貌似有点快，貌似？！对，因为目前优化还少，大部分工作在做后端的移植和调试工作。以后将会有优化和提升。所以不排除你的某些应用无法得到很高的加速。但是它毕竟有点快，使用Sun spider测试集，加速比1.73.我运行了gmail，速度还行，呵呵.详细的讨论见龙芯论坛的讨论贴loongson上firefox的nanojit支持

博主真絮叨，能做出这么牛的东西？

问的好！呵呵，不是我做的。是某牛人 zsc做的。我只是猥琐的趁机将其拿来为我的小博赚点流量。不过若你有什么问题，可以在lingcc.com，或者到上面的龙芯论坛的帖子中讨论:)

最近更新2010-01-14

改进正则表达式处理，nanojit加速比由1.73上升到2.18.增加Thundbird中的nanojit支持，
下载最新mozilla_1-1_mipsel.deb（有龙芯Nanojit支持的firfox,2010年1月14日)
下载最新thunderbird3-ls_1-1_mipsel.deb(有龙芯Nanojit支持的Thunderbird，2010年1月14日）
你也可以从这里找到详细的源码下载和编译指导：http://dev.lemote.com/code/firefox-3.7-loongson-jit/

为支持龙芯的开源爱好者们，加油！

Enjot it !

您可能也喜欢：
十年改变我们的那些技术	桃花庵歌	JOKE：新建域名不能访问和lingcc.net PageRank到3	再见2010，你好2011	永别2011, 你好2012
无觅

您可能也喜欢：
zzMozilla的疯狂构想 Firefox 4将开拓浏览器新疆界	JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm	webkit-龙小组成立	龙芯N32系统上的Squirrelfish性能	擦亮眼睛 “百度Hi”用户协议有猫腻
无觅

编译点滴 » 开源

淘宝code上线，局外人高兴一下

相关文章：

龙芯N32系统上的Squirrelfish性能

相关文章：

前瞻-主流处理器中的数据并行支持(SIMD)

引言部分：

SIMD 技术：

MMX技术：

流 SIMD扩展技术(SSE)

流SIMD扩展技术 2(SSE2)

流 SIMD扩展技术3(SSE3,SSSE3)

流 SIMD扩展技术4(SSE4)

流 SIMD扩展技5(SSE5)

高级向量扩展 (AVX)

3DNow!技术

小小结：

相关文章：

如果SourceForge.net沦为政治工具？

相关文章：

WebKit和Firefox的JavaScript性能对比

相关文章：

用crossdev装龙芯的n32 gnu交叉工具链

相关文章：

十年改变我们的那些技术

相关文章：

拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)

相关文章：