关于作者

用户名：bigblueSMTH
笔名：bigblueSMTH
地区：
行业：其他

日历 　年月日

日 一 二 三 四 五 六

快速登录

+ 用户名：
+ 密　码：

在线留言



Jiang的Wireless Sensor Network

http://spaces.msn.com/members/Robbie-Jiang/

mep的MSN空间

http://spaces.msn.com/members/mep/

访问统计：
文章个数:9
评论个数:12
留言条数:2




Powered by BlogDriver 2.1

bigblue@SMTH的博客

　

刚从水木搬过来， 满满地恢复元气。

文章

ISSCC2007新处理器


ISSCC2007
Session 05.0: 微处理器专题
Chair: Stefan Rusu, Intel, Santa Clara, CA
Associate Chaie: Jim Warnock, IBM, Youktown Heights, NY
2007年二月


    2007年的微处理器专题显示了各个主要处理器厂商加速迈向单芯片集成多个核心。与2006年的ISSCC微处理器专题论文相比，今年的微处理器许多都至 少有4个核心。Cache的容量也持续增加，典型on-die都有2-4MB的L2/L3 Cache。有两颗处理器使用了65纳米下11层金属互连，标志着集成度进一步提高。功耗仍然是关注的热点，所有的论文中都提到了特殊的有效功耗和降低漏 流的技术。大多数的设计都专注于低电压操作，展示了最小化supply-voltage reduction的电路技术，并且有两篇论文独立提出了对单个核心的独立动态电压调节技术。虽然整个业界都朝着多核心与功耗限制进行设计，主频提升仍然 是可能的，2007年处理器的主频又达到了新的纪录。


    Session的第一篇论文来自IBM的Power6芯片，双核心，主频达到5GHz。341mm2的Die上超过7亿只晶体管，使用65纳米10层互 连。Intel的论文涉及Tera-Scale项目，也是一个高主频设计；片上网络体系结构容纳了80个tiles，其中包括浮点计算核心与包交换路由 器，都工作在4GHz主频。Die上包含1亿只晶体管，使用65纳米工艺，使用各种电路技术来保证功耗小于100W，峰值性能达到1TFLOP。第三篇 Renesas日立电子的论文描述了一个4核心SoC结构，使用90纳米3电源电压(triple-Vt)CMOS工艺，8层互连。这一芯片使用了动态调 整各个核心在不同频率下工作的先进技术，可以大大降低平均工作功耗。100m2的Die面积达到了4320MIPS的性能，浮点性能为 16.8GFLOPS.

    在Session的第二部分，所有的4篇论文都描述了65纳米工艺下的多核心微处理器。第一篇是AMD公司的4核心Opteron处理器，和日立的论文一 样，这一设计也允许对单个核心的独立动态频率控制，芯片使用了65纳米的11层互连，片上集成4亿5千万只晶体管。每一个核心包括512KB的L2 Cache，2MB的L3 Cache被所有核心共享。来自PA-Semi公司的论文展示了双核心的节能SoC设计，两个2GHz的Power核心共享2MB的L2 Cache，使用一致性交叉开关互连，并集成存储和I/O子系统。115mm2的Die使用了65纳米8层互连技术。来自Intel的论文描述了双核心和 （MCM）四核心的Core体系结构实现。143mm2的Die使用了65纳米8层铜互连。共享的4MB L2 Cache使用了PMOS power gating来降低漏流。处理器的工作范围很广，工作电压从0.85v到1.325v，主频从1GHz到3GHz。来自Sun的论文描述了Niagara SPARC Soc的第二代芯片，8核心，64线程，比上一代设计的线程数增加了一倍。芯片上还集成了4MB L2 cache，一个x8的PCI-E，两个10G以太网端口和8个FBDIMM端口，342mm2使用65纳米3电源电压CMOS工艺，11层互连，片上共 有5亿只晶体管。



J.Friedrich. Design of the POWER6 Microprocessor . Paper 5.1
S.Vangal. An 80-Tile 1.28TFLOPS Network-on-Chip in 65nm CMOS. Paper 5.2
Y.Yoshida. A 4320MIPS Four-Processor Core SMP/AMP with Individually Managed Clock Frequency for Low Power Consumption. Paper 5.3
S.Searles. An Intergrated Quad-Core Opteron Processor. Paper 5.4
Z.Chen. A 25W SoC with Dual 2GHz Power Cores and Integrated Memory and I/O Subsystems. Paper 5.5
N.Sakran. Implementation of the 65nm Dual-Core 64b Merom Processor. Paper 5.6
U.Nawathe. An 8-Core 64-Thread 64b Power-Efficient SPARC SoC. Paper 5.7

- 作者： bigblueSMTH 2007年05月10日, 星期四 11:28　 回复（0） |　 引用（0） 加入博采

使用 GCC __attribute__和 link 脚本来控制section基地址
利用 GCC 的 __attribute__ 属性的section选项  来控制 数据区的基地址

样例代码 file: test.section.c

#include
#include


int localmemory0 __attribute__ ((section("LOCALmem")))=0;
int localmemory1 __attribute__ ((section("LOCALmem")))=0;

int globalmemory __attribute__ ((section("GLOBALmem")))=0;

int main (int argc, char * argv[])
{

        localmemory0 = 0x456;
        localmemory1 = 0x123;
         
        globalmemory = localmemory0 + localmemory1;
}

在上面的代码中定义了两个非传统Section  LOCALmem 和 GLOBALmem
要求变量 localmemroy0和变量localmemory0 存放在section  LOCALmem
而变量 globalmemory 存放在section GLOBALmem

首先使用命令行

gcc -c -o test.section.o test.section.c

或者

gcc -c -o test.section.o -fdata-sections test.section.c

获得目标代码 test.section.o
-fdata-sections选项的目的是让编译器为每一个单独申明的数据section实际分配一个section，而不是占用.bss，在某些系统上需要显式的使用这一参数

再使用objdump查看代码

objdump -S test.secton.o

获得如下结果

test.section.o:     file format elf32-i386

Disassembly of section .text:

00000000
:

   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 08                sub    $0x8,%esp
   6:   83 e4 f0                and    $0xfffffff0,%esp
   9:   b8 00 00 00 00          mov    $0x0,%eax
   e:   29 c4                   sub    %eax,%esp
  10:   c7 05 00 00 00 00 56    movl   $0x456,0x0
  17:   04 00 00
  1a:   c7 05 00 00 00 00 23    movl   $0x123,0x0
  21:   01 00 00
  24:   a1 00 00 00 00          mov    0x0,%eax
  29:   03 05 00 00 00 00       add    0x0,%eax
  2f:   a3 00 00 00 00          mov    %eax,0x0
  34:   c9                      leave
  35:   c3                      ret

注意到两条movl指令分别将数据存放到localmemory0和localmemory1，在leave指令之前的mov将加法结果存放到globalmemory中
由于是目标文件，变量符号对于的地址没有经过解析和分配，指令中变量对应的地址都是0x0。


使用一个link脚本script来控制链接器ld输出section的基地址。

file: sections.script

SECTIONS
{
  .text :
  {
    *(.text)
   }

  LOCALmem 0x1f0000 :
  {
    *(LOCALmem)
   }

  GLOBALmem 0xff0000 :
  {
    *(GLOBALmem)
  }

}

使用命令行：

ld -o test.section.elf -T section.script test.section.o

获得elf可执行文件链接结果 test.section.elf

这时使用 objdump 观看链接结构

命令行：

objdump -S test.section.elf

可以得到：

test.section.elf:     file format elf32-i386

Disassembly of section .text:

00000000
:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 08                sub    $0x8,%esp
   6:   83 e4 f0                and    $0xfffffff0,%esp
   9:   b8 00 00 00 00          mov    $0x0,%eax
   e:   29 c4                   sub    %eax,%esp
  10:   c7 05 00 00 1f 00 56    movl   $0x456,0x1f0000
  17:   04 00 00
  1a:   c7 05 04 00 1f 00 23    movl   $0x123,0x1f0004
  21:   01 00 00
  24:   a1 04 00 1f 00          mov    0x1f0004,%eax
  29:   03 05 00 00 1f 00       add    0x1f0000,%eax
  2f:   a3 00 00 ff 00          mov    %eax,0xff0000
  34:   c9                      leave
  35:   c3                      ret


使用 objdump -s test.section.elf 观察elf文件中所有内容可以看到：


test.section.elf:     file format elf32-i386

Contents of section .text:
 0000 5589e583 ec0883e4 f0b80000 000029c4  U.............).
 0010 c7050000 1f005604 0000c705 04001f00  ......V.........
 0020 23010000 a104001f 00030500 001f00a3  #...............
 0030 0000ff00 c9c3                        ......
Contents of section LOCALmem:
 1f0000 00000000 00000000                    ........
Contents of section GLOBALmem:
 ff0000 00000000                             ....
Contents of section .data:
Contents of section .comment:
 0000 00474343 3a202847 4e552920 332e322e  .GCC: (GNU) 3.2.
 0010 32203230 30333032 32322028 52656420  2 20030222 (Red
 0020 48617420 4c696e75 7820332e 322e322d  Hat Linux 3.2.2-
 0030 352900                               5).

Section LOCALmem从0x1f0000开始， 而Section GLOBALmem从0xff0000开始
程序正文段.text从0地址开始

如果将section.script中对于.text部分的内容去掉，那么ld产生的elf文件中.text部分
将紧接在GLOBALmem部分之后，从0xff0004开始

- 作者： bigblueSMTH 2006年08月29日, 星期二 11:24　 回复（0） |　 引用（0） 加入博采

google文件系统

Googlel文件系统


由于Google的文件存储使用上千的量产磁盘，因此存储失效并不再是意外，而是正常的事情。应用程序Bug，操作系统Bug，人为操作失误，电力，网络，内存或者磁盘本身的问题都可能造成存储内容失效或者不可恢复，因此内建容错、失效检查和自动错误恢复是必需的选择。


Google经常操作的是大尺寸文件，数GB的文件大小非常常见，需要在磁盘I/O的时候对这样的访问进行支持。小尺寸(数KB)的文件也需要支持，单没有必要为数量众多的小文件存储做优化。

Google的文件写操作经常是在原有数据后面添加内容，而不是改写原有数据。因此需要对增加内容的操作进行优化，重新考虑“生产者－消费者”队列、原子性保护和并行访问的控制。随机的访问，对文件内部某部分数据的修改也需要支持，但这并不是优化和提高性能的重点。

在文件系统的设计的同时也提供相应的API，并不需要遵循POSIX的文件系统调用标准，同时也不需要改动Linux内核。但是额外的诸如并行添加文件内容的API将会提高效率。


- 作者： bigblueSMTH 2006年04月9日, 星期日 23:56　 回复（0） |　 引用（0） 加入博采

多核心处理器的冷水
多核心是微处理器市场最新的救命稻草，但是在经历过高主频P4性能低于P3之后，在多核心上的怀疑眼光越来越多。对于大多数用户而言最需要的是单个主要应用的性能增强，例如漫长的3D渲染和EDA综合，仅仅使用多核心似乎并不能解决这个问题。


STAR: STR-01M-01-2005-1107
标题： Multicore CPUs for the Masses
作者： Mache Creeger (bigblue@newsmth.org译存)

来源： acmqueue杂志vol.3 no.7 http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=333

Multicore CPUs for the Masses
多核心处理器盛行

ACM Queue vol.3, no.7 September 2005

Author:  Mache Creeger, Emergent Technology Associates

Will Incresed CPU Bandwidth Translate into Usable Desktop Performance?

不断提升的处理器带宽可以转换为可得到的桌面系统性能么？


多核心是Intel、AMD和SUN最新一轮处理器的新概念。由于提高时钟主频变得越来越困难，制造商选择多核心处理器作为获取额外性能的最佳选择。消费者就象面对地产商一样为并行处理器所许诺的性能提升而激动。


对于屈指可数的主流企业级服务器应用而言，这可能是真的，但是对于桌面应用而言，并行处理器的性能承诺不太可能在短时间内成为可能。对桌面多核心处理器的期望是，所有的桌面应用都能够完全利用芯片中的所有处理器核心。每一个应用的性能都可以获得巨大的提升，因为越来越多的核心可以被使用。就像以前在时钟主频和应用带宽上的提高，增加处理器核心的数目应该能够获得类似的性能提高。这对于主流的企业级服务应用而言是真的，对桌面应用又怎么会例外呢？听起来没有什么问题，是吧？但是别指望（就像别指望中国的地产商一样）。

确实，主流的企业级应用例如Oracle，WebLogic，DB2和Apache是按照充分使用多核心处理器设计，并按照多线程(MT: Multithreaded)构建的。由于大规模的对称多处理SMP是这一市场的主流，他们不得不满足这些要求。

虽然使用多个并行处理器来提高整个元件的性能的概念已经提出来至少35年了，极少有可称道开发工具让这一观点进入主流商业市场。这造成绝大多数应用都是单线程的。虽然多核心处理器允许多个应用共享多个执行核心，单个应用的性能却被单一处理器的速度限制。由于在任何给定的时间之内每一个应用只能在一个处理器上运行，不论使用100个处理器或者一个核心，软件获得的性能都是相同的。

除了Java可能算个例外，目前并没有被广泛使用、包含多线程扩展的开发语言。事实上，到目前为止都没有足够的需求。商用SMP的大规模普及直到90年代早期才开始，即使在那时多线程应用的开发也很缓慢。

当作者Creeger在SUN工作时，SUN重写了SunOS以从多线程体系结构中获益。重写时一个漫长而痛苦的过程。开始的时候，子系统都需要在两端加锁的条件下重写，以保证子模块能作为单独的一个大线程运行(MT-safe)，接下来以多线程最优化的方式(MT-hot)再次重写以获得最大的并行性。所有的一切都是手工设计，没有任何工具来控制复杂度。

与此同时，Sun实现了一组用户级多线程库给外围应用使用。由于大规模SMP服务器开始出现在Sun的规划图中，主流的企业级应用开发商发现他们也不得不投资将自己的软件变为多线程的。这个过程和SunOS的多线程重构一样的痛苦。Sun意识到需要应用也转变为MT-hot才能让SMP畅销，因此开始向各个开发商派遣的自己的工程师来帮助他们加快完成移植。

现在的情形简直就是10年前的翻版。需要更大处理器带宽的应用开发商不能构再指望主频速度带来更高的性能和功能。大多数广泛使用的客户端应用都是用C和C++写的，一直按单线程结构设计。将应用转换为多线程MT-hot仍然是一个劳动密集的苦差事。虽然一部分开发商，特别是多媒体领域的人已经在他们的应用中做了某些多线程的增强，这也只不过是摘了矮枝上的果实。在多核心处理器上看到广泛的桌面应用性能提升和功能进步将是多年以后的事情。

多线程体系结构发展的十多年来开发工具的厂商都做了写什么？并非所有计算机工业界的人都没有预见到这一点。我们将来需要什么？这取决于业界目前的做法，当消费者发现他们的大多数应用并不能在双核心或者四核心系统上比单核心有什么提高的话，多核心桌面处理器的推广就会停滞。为了销售更多的处理器，硬件厂商不得不复制Sun的做法，鼓励软件开发商重新设计他们的软件，转换到MT-hot方式。以往可以依赖处理器持续主频增长的桌面应用开发商将有一个漫长和痛苦的投资过程，将软件重写来获得在性能和功能上的下一个飞跃。所有这些将需要数年的时间。此外，反应迅速的公司现在可以用更快速的MT-Hot投资和开发从那些反应缓慢的公司争取到客户。

令人沮丧的是这一切其实都是可以避免的。多线程已经出现超过十年。由于技术公司在制定计划时的目光短浅，他们错过了多核心处理器在桌面上的更大的可发展趋向。结果，相关的多线程开发工具并没有伴随新处理器面向市场。除了Java仅有的多线程支持，开发工具商与企业级应用开发商十多年前面临的情况非常相似。

可悲的是将来的场景。应用开发商将花费数年的痛苦过程来重写代码实现MT-hot。只要代码变换的方法学能够确立，IDE工具商将开始建立自动扩展来控制多线程开发的复杂度。这两个过程很容易消耗3－5年的时间。一旦MT增强的IDE产品建立，语言的扩展随之而来。商业上被接受的完全集成多线程控制结构的开发语言将需要5-7年来普及。在这之前，不要指望在新的处理器上桌面应用的性能有什么飞跃。对于多核心系统，桌面上拥有的处理器带宽和能够使用这一能力是两个完全不同的概念。

- 作者： bigblueSMTH 2006年04月8日, 星期六 16:23　 回复（0） |　 引用（0） 加入博采

交叉编译工具集
由 Dan Kegel维护的CrossTool工具，居然可以满足那么多结构。不过GCC和Kernel实在捆绑的太紧了，所以还是有那么多的组合无法得到满意的CrossCompiler工具集合。不过每个结构都有一组合适的配置能够正常工作，除了太BT的要求，应该是够用了。
 
 各种组合参见

- 作者： bigblueSMTH 2006年02月27日, 星期一 21:00　 回复（0） |　 引用（0） 加入博采