Xbox 360肚子里的Xenon有3个相同的PowerPC core，共享1M 2级缓存。作者把每个core叫做PowerPC Processing Element (PPE)。每个PPE有独立的64Kcache，指令和数据各占一半。通过simultaneous multithreading (SMT)，每个PPE同时最多可以处理2个线程。对整个Xenon 来说，就是同时6个。使用procedural rendering 的游戏终归能从这个特性中受益。按Microsoft的专利所说，使用上述技术的游戏有这样两个主要部分：
        Host thread：包括游戏的主要执行部分，这个线程将管理3D引擎的高阶部分，并且控制下面这个Host thread线程。
        Host thread：完成目标几何数据的真正procedural synthesis过程。该线程输出游戏中各种对象的顶点列表，交GPU处理。
        这两个线程可以跑在同一个PPE上，或者两个PPE上。处理上述两个线程，游戏里还可以有其他独立线程完成AI,IO等工作。
        后面是Cache。Xenon 提供了更多编程控制Cache的能力。
       
        第一部分的概要介绍后，第二部分详细描述了Xenon的设计和实现。首先是传统的增加执行core数量的方法带来的困境，之后是Xenon的设计：
        Cell 和 Xenon 有共通的基本概念：去掉那些试图在运行时优化指令调度的硬件，降低执行core的复杂度。Cell 和 Xenon都摒弃了instruction window，不再强调instruction-level parallelism，指令就老老实实地按照他们被取出的次序流过CPU，当然，如果相邻指令没有相互依赖，就仍然并发执行。
        这样的静态执行机制很像那些过时的老家伙们采用的方法－－比如奔腾。静态执行很容易实现，并且占用更少的die。没了instruction window 和相关硬件，instruction window省下来的空间可以放置更多的真正的执行单元。
        当然你不能一脚踢开instruction window然后用更多的执行单元取而代之就万事大吉甩手不管，总的做点什么来补偿去掉instruction window带来的一些tradeoff－－既然instruction window的概念是要让多执行单元情况下提高instruction-level parallelism，那么去掉了instruction window的多执行单元芯片，就得重新考虑如何组织CPU。
       
        Xenon不再依靠instruction window在运行时决定ILP，它更酷，让程序员在编译时安排指令流，这样代码中包含了高层的线程级并行TLP。XBox 360的程序员们要辛苦一些，对他们的要求也高一些。在把大量的执行单元组织到3个core里面之后，每个core独立地包含相对数量较少的执行单元，经过程序员安排的指令流形成的多个并行线程就在这些独立的core上运行。最终结果是每个线程的ILP值可能比较低，但是总的组合效果是3个PPE里的所有执行单元都出于出工出力的状态，效率颇佳。据称TLP策略对procedural synthesis这样线程级并行的任务尤其有效－－不过相比那些天生就是单线程的任务在此前的大执行单元+巨大的instruction window架构上的表现，还是没那么好。3种游戏相关任务可能会受到Xenon这种缺乏乱序执行功能的芯片的负面影响：游戏控制，AI和Physics。
        Xenon PowerPC Processing Element 细节是：
        L1 cache: 32K instructions/32K data
        Two-issue superscalar execution
        In-order execution
        Two-way simultaneous multithreading
       
        PPE 流水线
        
        
        关于PPE的execution core。确切地说，组成PPE execution core的execution unit的数量和性质还没有正式透露。推测来说PPE 的执行单元（execution unit）：
        1 integer unit
        1 floating-point unit
        1 branch unit
        1 load-store unit
        2 VMX-128 units
        最引人瞩目和让人迷惑的是Xenon的向量执行单元（或者说SIMD执行单元），它将主要完成前面提到的procedural synthesis。
        Xenon的VMX将提供128个寄存器，每个128位－－老实说，对我们这样大多数还活在32位，有时会回到16位甚至8位时代的人来说，这个特性非常非常bleeding-edge......这也就是VMX-128名字的来历吧。
        每个线程都可以使用这128个向量寄存器，按照 128寄存器 * 2 线程 来算，die上就有256个物理向量寄存器。
        目前PPC的32位指令格式如何适配这个3操作数每个操作数都可以达到128位的怪物还不清楚。IBM会玩什么hack招术还是秘密。
        关于VMX-128的另一个消息是，为了提高性能，128个好汉中将会拿出一些来构成寄存器pool，pool中的寄存器被多个函数调用共享－－只要他们在同一个线程内。

        Simultaneous multithreading－－当然，我不知道翻成并发还是并行，还是并行比较好。
        和超线程P4比，Xenon的SMT实现非常非常简单。不过似乎PPE的总设计和P4的Netburst架构有相当多的类似之处（莫非英雄所见略同...）。他们的设计哲学都是narrow and deep，当然PPE有些非常重要的不同。
        PPE的流水线有21阶，和Northwood P4相同（Prescoot？我也不知道了...）。Xenon的PPE有32K指令和32K数据cache，对双线程和较深的流水线来说，似乎有点小。PowerPC 970的23阶流水线有64K指令/数据cache，而PowerPC G4的7阶流水线就有32K指令/数据Cache。不过，这并不是Xenon的灾难，实际上32K指令/数据1级cache很通用，而且当它作为一个游戏机芯片的时候，性能影响就更微乎其微了。因为在Xbox 360 这样的游戏应用中，开发者对硬件和cache层级可以做到非常细微的控制，如果把Xenon拿去搭建常规应用，比如苹果机，那恐怕就确实有点麻烦了。
        同样，Xenon的1MB 2级缓存挺起来好像也有点出乎意料－－出乎意料地小－－特别是对一个3核CPU来说。理论上，共享cache的core越多，这个cache似乎就该越大。不过实际上，准确地说，应该是共享cache的并发执行线程越多，这个cache就该越大－－不过，有点搬起石头砸自己脚的是，在这个看法下，Xenon的cache更不适合了－－因为一个Xenon的 core支持两路多线程，这样算下来，最多会有6个线程共享1M 2级cache。当然，IBM的家伙不是无厘头，他们这样设计较小的2级cache有2个重要原因：
        第一，在有限的die尺寸上搞出一个3核CPU不那么简单，没那么多空地儿留着给cache（希望上海市政府也明白同样道理，少批点儿地造cache那样的高档楼，留点儿地皮给咱们，上海这个die就只有这么大了）。Xenon 已经巨无霸到要用水冷设备才能工作了，再大就不象话了。
        第二，更重要的原因是，流媒体streaming media－－特别是Xenon－－使用cache的方式，决定了1级cache这么大足够了。Xenon 面向的应用场合，并不会非常有效地利用cache。这种Media application通常都会让流数据快速流动，cache很少会被复用。一个实证是赛扬，玩Quake 的时候，没有cache的赛扬几乎和它配了cahce的哥们奔二一样快。
       
        深流水线的另一个问题是分支预测。PPE当然有这个功能。由于缺少资料，目前可以推断的是，PPE的分支预测错误率可能会高于PowerPC 970。PPE的策略似乎更期望软件上提供branch hints，而且硬件完成的分支预测工作较少，就意味着这样的software branch hints更有效。Xenon－－－哦，还有Cell－－的程序员们，加油，branch hints 的活儿，更好的游戏性能就靠你们了。

        和PS3的Cell一样，XBox 360的Xenon和它的前辈差异巨大，策略迥异。利用procedural synthesis和多线程，XBox 360能营造出比现在的任何游戏设备或者PC都更具吸引力的视觉环境。
        对那些分支敏感代码，比如AI和控制，Xenon的表现可能是普通甚至很差。Xenon绝对会是个streaming media monster，但是如果不算面子漂亮的活儿的话，游戏引擎中那些让游戏更好玩的因素恐怕会在Xenon上受到伤害。太小的2级cache会让AI和控制部分表现不好－－他们必须得同procedural synthesis以及其他图形代码共享这可怜的1M－－程序员们得好好费费劲才能让这些非图形代码获得高性能。
        虽然Xenon可以同时运行6个线程，但是上面说的AI和控制等分支敏感代码不具备图形代码那样高的线程级的并行特性，6个线程英雄无用武之地。同样这些在乱序执行CPU上可以撒欢儿的代码也不能从Xenon的顺序执行策略中受益。
        所以，最终结果是，XBox 360为开发者提供了绝佳的图形资源，但是要求他们在游戏的非图形因素上花费多点精力。其实换个角度也可以这么看，在PC市场上，开发者要支持多种CPU，他们没法为某种CPU进行专门的性能调整和优化。这种异构性伤害了branch hints这样的优化手段。相比之下，Xenon还算好了，硬件平台是确定的，开发者至少有机会可以全力进行profiling啊，优化啊等等，所以上面所说的控制和AI部分的劣势可以得到一定弥补。随着Xenon的使用，开发者们总有办法找到解决办法对付分支敏感代码的执行效率之类的问题－－这不就是人的力量嘛－－当然，游戏fans不能指望第一代游戏就这么好 ;-P
        既然看了Xenon，也顺顺展望一下它的同门PS3的Cell－－它恐怕会更差。Cell只有1个PPE－－Xenon有3个，这意味着程序员得把控制，AI和真正的代码塞到最多2个线程里－－共享narrow execution core，而且没有instruction window。PS3的SPE甚至根本不支持分支预测。此外，PS3的2级cache更穷，只有521K，Xenon的一半。简短地说，在非图形代码上，PS3会比XBox 360更差，但是借助PS3的7个SPE，它的游戏画面就比XBox 360强多了。

        显然白痴都知道一种游戏机的成功与否取决于包括但不限于处理器架构以外的相当多因素，不过既然XBox 360的架构和PS3将采用的Cell有很多共通之处，他们似乎在接近一个共同的起跑线，让人们更能饶有兴致地坐家观虎斗。