R******o
发帖数: 1572 | 1 隔壁的某些213又被打脸了
Last week, Qualcomm chief marketing officer Anand Chandrasekher called Apple
's new 64-bit A7 processor a "marketing gimmick" and claimed the processor
had very few consumer-driven features.
Today, Qualcomm is backing away from those comments, according to Macworld.
A company spokesperson issued this statement to the magazine:
"The comments made by Anand Chandrasekher, Qualcomm CMO, about 64-bit
computing were inaccurate," said a Qualcomm spokesperson in an email. "The
mobile hardware and software ecosystem is already moving in the direction of
64-bit; and, the evolution to 64-bit brings desktop class capabilities and
user experiences to mobile, as well as enabling mobile processors and
software to run new classes of computing devices."
64-bit processing marks a major advance for mobile CPU-makers and will be
extremely important for Qualcomm going forward, as the firm has announced
that it too is working on such chips. Given the flurry of attention
regarding Chandrasekher's comments and Qualcomm's own ambitions in the area,
it makes sense for the company to try to walk back the "marketing gimmick"
remarks. |
d***a
发帖数: 13752 | 2 对做一行的人来说，非常明显，使用ARM架构，从两核上四核之前，应该
先上64位ARM架构。
苹果最近的一系列设计，技术决策上做得扎实合理。相比之下，安卓阵营
技术方向上比较混乱，讨好用户的味道相当浓厚。一些半懂不懂的用户还
很吃这一套。 |
m*********t
发帖数: 1250 | 3 完全不知所云~
64bit CPU + 2GB （<4GB） Memory 叫技术上扎实合理？世界上目前还没有比Apple更会
“讨好用户”的吧？弄个土豪金还搞饥饿营销，5C就是换个彩色塑料马甲也成新一代了
~ 其实果粉主要自己喜欢买就好，其他的理由都可以一律无视，大家也都能理解的~
【在 d***a 的大作中提到】
: 对做一行的人来说，非常明显，使用ARM架构，从两核上四核之前，应该
: 先上64位ARM架构。
: 苹果最近的一系列设计，技术决策上做得扎实合理。相比之下，安卓阵营
: 技术方向上比较混乱，讨好用户的味道相当浓厚。一些半懂不懂的用户还
: 很吃这一套。
|
g*******t
发帖数: 7704 | 4 64不64不重要， 几核也不重要，apple在芯片设计方面突破了，
browser里测试数据把高通远远抛开，
高通就是羡慕嫉妒恨， |
d***a
发帖数: 13752 | 5 呵呵，不理解也是正常的。这东西本来就是少数技术人员的事。
更会
【在 m*********t 的大作中提到】
: 完全不知所云~
: 64bit CPU + 2GB （<4GB） Memory 叫技术上扎实合理？世界上目前还没有比Apple更会
: “讨好用户”的吧？弄个土豪金还搞饥饿营销，5C就是换个彩色塑料马甲也成新一代了
: ~ 其实果粉主要自己喜欢买就好，其他的理由都可以一律无视，大家也都能理解的~
|
s******s
发帖数: 13035 | 6 其实果果也是满郁闷的. 以前是隐藏技术赚口碑, 现在只能学三爽刷分了.
【在 g*******t 的大作中提到】
: 64不64不重要， 几核也不重要，apple在芯片设计方面突破了，
: browser里测试数据把高通远远抛开，
: 高通就是羡慕嫉妒恨，
|
N*******3
发帖数: 2589 | 7
以前安卓只能靠分数取胜，结果现在连这块都没了。
【在 s******s 的大作中提到】
: 其实果果也是满郁闷的. 以前是隐藏技术赚口碑, 现在只能学三爽刷分了.
|
c******2
发帖数: 3170 | 8 虽然我很外行，但我对此还是持保留意见。要知道PS2上早就用上128位的cpu，所以用
多少位要考虑的因素是多方面的。如果兼容性和性能提升那么容易两全，windows也不
用搞那么多年的32位和64位系统并存。而且一开始几年，大家对64位系统的抱怨可是一
点也不少的。即便到了今天，如果你没有用超过4g的内存，用32位系统基本没有差别，
对大多数应用而言，32位和64位本身也毛有差别。而apple app的立国之本可是小软件
。所以，64位是未来的方向，5s上用也是好事情，但是本身对性能的影响应该是几乎等
于没有的，真正的提升在于速度和其他构架方面的进步。64位对于5s最大的意义还在于
是一个响亮的噱头。
【在 d***a 的大作中提到】
: 呵呵，不理解也是正常的。这东西本来就是少数技术人员的事。
:
: 更会
|
s****c
发帖数: 11300 | 9 原来64bit就是为了访问大内存 全世界搞硬件的人都惊呆了
更会
【在 m*********t 的大作中提到】
: 完全不知所云~
: 64bit CPU + 2GB （<4GB） Memory 叫技术上扎实合理？世界上目前还没有比Apple更会
: “讨好用户”的吧？弄个土豪金还搞饥饿营销，5C就是换个彩色塑料马甲也成新一代了
: ~ 其实果粉主要自己喜欢买就好，其他的理由都可以一律无视，大家也都能理解的~
|
b****t
发帖数: 5743 | 10 任天堂当年N64的把戏现在转到smartphone上还能玩得动，真是神奇啊 |
|
|
r***i
发帖数: 913 | 11 总有人以为32bit和64bit在<4GB是没分别的，呵呵
【在 d***a 的大作中提到】
: 呵呵，不理解也是正常的。这东西本来就是少数技术人员的事。
:
: 更会
|
a****l
发帖数: 8211 | 12 从道理上说当然64位是方向，不是64位难道是16位才是方向？
Apple
.
of
and
【在 R******o 的大作中提到】
: 隔壁的某些213又被打脸了
: Last week, Qualcomm chief marketing officer Anand Chandrasekher called Apple
: 's new 64-bit A7 processor a "marketing gimmick" and claimed the processor
: had very few consumer-driven features.
: Today, Qualcomm is backing away from those comments, according to Macworld.
: A company spokesperson issued this statement to the magazine:
: "The comments made by Anand Chandrasekher, Qualcomm CMO, about 64-bit
: computing were inaccurate," said a Qualcomm spokesperson in an email. "The
: mobile hardware and software ecosystem is already moving in the direction of
: 64-bit; and, the evolution to 64-bit brings desktop class capabilities and
|
d***a
发帖数: 13752 | 13 把64位和4G内存联系起来是最近的事。实际上，八十代末和九十年代初，64位计算就开
始在高性能工作站上广泛使用了，比如说Sun SPARC, SGI MIPS, IBM Power系列。那时
硬盘空间还是以MB来标的，更别说内存了，离4GB上限远着呢。
64位计算是提高性能的简单有效的方法，对做这一行的人来说，是常识性的知识。高通
的Anand做的那个评论，从市场宣传来说没什么，从技术上说是明显不对的。这大概是
为什么高通会发那样一个声明来更正一下。
【在 c******2 的大作中提到】
: 虽然我很外行，但我对此还是持保留意见。要知道PS2上早就用上128位的cpu，所以用
: 多少位要考虑的因素是多方面的。如果兼容性和性能提升那么容易两全，windows也不
: 用搞那么多年的32位和64位系统并存。而且一开始几年，大家对64位系统的抱怨可是一
: 点也不少的。即便到了今天，如果你没有用超过4g的内存，用32位系统基本没有差别，
: 对大多数应用而言，32位和64位本身也毛有差别。而apple app的立国之本可是小软件
: 。所以，64位是未来的方向，5s上用也是好事情，但是本身对性能的影响应该是几乎等
: 于没有的，真正的提升在于速度和其他构架方面的进步。64位对于5s最大的意义还在于
: 是一个响亮的噱头。
|
d***a
发帖数: 13752 | 14 哈哈...宣传的力量是强大的。
【在 s****c 的大作中提到】
: 原来64bit就是为了访问大内存 全世界搞硬件的人都惊呆了
:
: 更会
|
w*******e
发帖数: 285 | 15 你觉得64位的主要优势在什么地方呢？
pc从x86到x64,不光是地址变成64位了，还有calling convention从压栈变成了rcx,rdx
,r8,r9寄存器传递，参数超过4个才再压栈，就这样由于指针double了所以可执行文件
增加30%，就算内存够用，cache miss的概率也会增加，32位和64位程序的执行速度基
本一样。我觉得64位相对于32位的主要优势除了fast calling convention还是可以方
便利用大内存，虽然32位的pae mode也可以，但是对于普通app很不方便。
arm跟pc不同，v7（a15)本来就用fast calling convention，参数就在r0 到 r3里面，
这点v7和v8没有多大变化。所以在小内存下从32位到64位的好处真的很难说。apple和
qualcomm一样，都是architecture license arm的标准，就是说可以拿来蓝图自己改进
，apple的a7和arm v8标准一个重要不同就是它支持在user mode运行32位程序，就跟64
位pc运行32位程序的wow64 mode差不多。现在这么做是必需的，否则所有现有app都要
重新编译一遍。
我觉得这是为了将来等到内存真的变大了，apple也可以推出64位only的cpu, 那时候
app已经都是64位了，就不用再支持32位了，另外也可能是apple想试探彻底摆脱intel
的可能性，如果64位arm很成功，也许将来他们的笔记本也会有arm版本的。
【在 d***a 的大作中提到】
: 把64位和4G内存联系起来是最近的事。实际上，八十代末和九十年代初，64位计算就开
: 始在高性能工作站上广泛使用了，比如说Sun SPARC, SGI MIPS, IBM Power系列。那时
: 硬盘空间还是以MB来标的，更别说内存了，离4GB上限远着呢。
: 64位计算是提高性能的简单有效的方法，对做这一行的人来说，是常识性的知识。高通
: 的Anand做的那个评论，从市场宣传来说没什么，从技术上说是明显不对的。这大概是
: 为什么高通会发那样一个声明来更正一下。
|
c******2
发帖数: 3170 | 16 关键在于提升性能的同时必须兼顾与之前软件的兼容，而不能真正推倒重建，不然大家
随便搞个128位的cpu都没有太大的难题。单说PC上的cpu，即便到现在，还有一堆的32
位程序运行在64位的cpu上。64位cpu的最大优势还真是对大内存的支持，另外也许就是
运行某些大型程序上的优势吧。看不出智能手机领域能有什么质的差别。
【在 d***a 的大作中提到】
: 把64位和4G内存联系起来是最近的事。实际上，八十代末和九十年代初，64位计算就开
: 始在高性能工作站上广泛使用了，比如说Sun SPARC, SGI MIPS, IBM Power系列。那时
: 硬盘空间还是以MB来标的，更别说内存了，离4GB上限远着呢。
: 64位计算是提高性能的简单有效的方法，对做这一行的人来说，是常识性的知识。高通
: 的Anand做的那个评论，从市场宣传来说没什么，从技术上说是明显不对的。这大概是
: 为什么高通会发那样一个声明来更正一下。
|
w*******e
发帖数: 285 | 17 64位arm当然是方向，但是我觉得首先是在server端吧，要运行大内存的程序，要支持
vm，都比较需要有大内存，a15不是不可能，但是太麻烦了，估计很多软件开发商都会
直接跳过等64位。
32
【在 c******2 的大作中提到】
: 关键在于提升性能的同时必须兼顾与之前软件的兼容，而不能真正推倒重建，不然大家
: 随便搞个128位的cpu都没有太大的难题。单说PC上的cpu，即便到现在，还有一堆的32
: 位程序运行在64位的cpu上。64位cpu的最大优势还真是对大内存的支持，另外也许就是
: 运行某些大型程序上的优势吧。看不出智能手机领域能有什么质的差别。
|
g*******t
发帖数: 7704 | 18 对于高精度计算，64位肯定有优势，
对于普通browser， 64位是否提高性能，还没有数据证明， |
s******s
发帖数: 13035 | 19 安卓说: 我有大屏
哈哈哈
【在 N*******3 的大作中提到】
:
: 以前安卓只能靠分数取胜，结果现在连这块都没了。
|
d***a
发帖数: 13752 | 20 64位的主要优势在什么地方...这是教科书上的内容了。从技术决策上说，苹果上64位
是中规中矩的教科式做法，没有什么特别的地方。苹果做的对的，是没有随大流上四核
。那样虽然有利于市场宣传，但并不是技术上合理的做法。
单从寄存器使用来说，从ARMv7到ARMv8，寄存器增加了很多。ARMv7只有16个寄存器，
其中r15还被用为PC，r13是stack pointer，r14是link register，所以真正能用的就
13个。ARMv8把寄存器增加到32个，减少了register spill，参数传寄也有更多机会只
用寄存器传寄。
rdx
64
【在 w*******e 的大作中提到】
: 你觉得64位的主要优势在什么地方呢？
: pc从x86到x64,不光是地址变成64位了，还有calling convention从压栈变成了rcx,rdx
: ,r8,r9寄存器传递，参数超过4个才再压栈，就这样由于指针double了所以可执行文件
: 增加30%，就算内存够用，cache miss的概率也会增加，32位和64位程序的执行速度基
: 本一样。我觉得64位相对于32位的主要优势除了fast calling convention还是可以方
: 便利用大内存，虽然32位的pae mode也可以，但是对于普通app很不方便。
: arm跟pc不同，v7（a15)本来就用fast calling convention，参数就在r0 到 r3里面，
: 这点v7和v8没有多大变化。所以在小内存下从32位到64位的好处真的很难说。apple和
: qualcomm一样，都是architecture license arm的标准，就是说可以拿来蓝图自己改进
: ，apple的a7和arm v8标准一个重要不同就是它支持在user mode运行32位程序，就跟64
|
|
|
d***a
发帖数: 13752 | 21 对browser没用，对相机App来说就大有用处了。5S相机性能的提高，连拍速度有那么快
，和A7有很大关系。
【在 g*******t 的大作中提到】
: 对于高精度计算，64位肯定有优势，
: 对于普通browser， 64位是否提高性能，还没有数据证明，
|
d***a
发帖数: 13752 | 22 "64位cpu的最大优势还真是对大内存的支持"，完全不是这么回事。64位用
了都有几十年了，标准的提高性能的做法。
Windows操作系统最开始时做很糟糕，所以上64位要吭叽很久。Unix系统
上64位，很简单的事情。这不，iOS没什么动静就上64位了，并且5S实测出
来的性能比A6时提高很多。
32
【在 c******2 的大作中提到】
: 关键在于提升性能的同时必须兼顾与之前软件的兼容，而不能真正推倒重建，不然大家
: 随便搞个128位的cpu都没有太大的难题。单说PC上的cpu，即便到现在，还有一堆的32
: 位程序运行在64位的cpu上。64位cpu的最大优势还真是对大内存的支持，另外也许就是
: 运行某些大型程序上的优势吧。看不出智能手机领域能有什么质的差别。
|
a***e
发帖数: 27968 | 23 64bit almost has nothing to do with the FPU.
32bit CPU could have the same DP FPU.
for RISC, you might see quite some benefit from 32 to 64 ISA
when using DP FPU though.
【在 g*******t 的大作中提到】
: 对于高精度计算，64位肯定有优势，
: 对于普通browser， 64位是否提高性能，还没有数据证明，
|
a***e
发帖数: 27968 | 24 that is ARM ISA perticular problem.
can not be generalize to 32->64 case.
A53 is simpler and faster than A9 performance b/c inherent issues with v7.
these cores are out there for a year now.
it might get pull in quickly.
【在 d***a 的大作中提到】
: 64位的主要优势在什么地方...这是教科书上的内容了。从技术决策上说，苹果上64位
: 是中规中矩的教科式做法，没有什么特别的地方。苹果做的对的，是没有随大流上四核
: 。那样虽然有利于市场宣传，但并不是技术上合理的做法。
: 单从寄存器使用来说，从ARMv7到ARMv8，寄存器增加了很多。ARMv7只有16个寄存器，
: 其中r15还被用为PC，r13是stack pointer，r14是link register，所以真正能用的就
: 13个。ARMv8把寄存器增加到32个，减少了register spill，参数传寄也有更多机会只
: 用寄存器传寄。
:
: rdx
: 64
|
d***a
发帖数: 13752 | 25 64位对32位有优势。对ARM架构来说，因为ARMv7的具体原因，
ARMv8对ARMv7优势会比别的架构，比如说MIPS64对MIPS32，
来得更大，这是ARMv8在设计时就预计到了。苹果实证了确实
是这样。
A53和A57是很有意思的设计。Cortex-A15则做得不好。
【在 a***e 的大作中提到】
: that is ARM ISA perticular problem.
: can not be generalize to 32->64 case.
: A53 is simpler and faster than A9 performance b/c inherent issues with v7.
: these cores are out there for a year now.
: it might get pull in quickly.
|
a***e
发帖数: 27968 | 26 Sun moved to ultrasparc in 1995. in server end,
enterpise sparc server already got 4GB no later than 1997.
this is the era x86 started to gain lead in performance in 32bit
and slowly squeeze these cpus out of market.
【在 d***a 的大作中提到】
: 把64位和4G内存联系起来是最近的事。实际上，八十代末和九十年代初，64位计算就开
: 始在高性能工作站上广泛使用了，比如说Sun SPARC, SGI MIPS, IBM Power系列。那时
: 硬盘空间还是以MB来标的，更别说内存了，离4GB上限远着呢。
: 64位计算是提高性能的简单有效的方法，对做这一行的人来说，是常识性的知识。高通
: 的Anand做的那个评论，从市场宣传来说没什么，从技术上说是明显不对的。这大概是
: 为什么高通会发那样一个声明来更正一下。
|
d***a
发帖数: 13752 | 27 Sun SPARC used 64-bit before UltraSPARC did. 4GB was out of question then.
【在 a***e 的大作中提到】
: Sun moved to ultrasparc in 1995. in server end,
: enterpise sparc server already got 4GB no later than 1997.
: this is the era x86 started to gain lead in performance in 32bit
: and slowly squeeze these cpus out of market.
|
w*******e
发帖数: 285 | 28 这篇文章很不错
http://www.anandtech.com/show/7335/the-iphone-5s-review/4
大部分情况下a7的64位cpu和更多的通用寄存器还是很有帮助的，但是对于像Dijkstra
这样大量用到指针的算法，cache miss也是一个考虑，结果导致了相对32位的
regression。当然对于大多数workload还不至于。
【在 d***a 的大作中提到】
: Sun SPARC used 64-bit before UltraSPARC did. 4GB was out of question then.
|
i*********e
发帖数: 1010 | 29 L1 cache加倍抵消cache miss
剩下主要问题就是加大L1 cache增加的latency
Dijkstra
【在 w*******e 的大作中提到】
: 这篇文章很不错
: http://www.anandtech.com/show/7335/the-iphone-5s-review/4
: 大部分情况下a7的64位cpu和更多的通用寄存器还是很有帮助的，但是对于像Dijkstra
: 这样大量用到指针的算法，cache miss也是一个考虑，结果导致了相对32位的
: regression。当然对于大多数workload还不至于。
|
c****p
发帖数: 6474 | 30 64位整数运算性能提升30%左右。
剩下的A7 vs A6的一倍性能提升从哪儿来？反正肯定不全是64位干的。
苹果这个一倍性能提升的说法把诸如guvest之类的人忽悠惨了。。
【在 r***i 的大作中提到】
: 总有人以为32bit和64bit在<4GB是没分别的，呵呵
|
|
|
m*****e
发帖数: 33 | |
c****p
发帖数: 6474 | 32 L1 Cache不是想加倍就加倍的。
芯片面积、时序、功耗问题有很多。
【在 i*********e 的大作中提到】
: L1 cache加倍抵消cache miss
: 剩下主要问题就是加大L1 cache增加的latency
:
: Dijkstra
|
i*********e
发帖数: 1010 | 33 不是已经确认32kB加倍了么？
再说L1那么小，功耗、面积占不多吧
主要是延迟加大 对L1性能直接影响
★ 发自iPhone App: ChineseWeb 7.8
【在 c****p 的大作中提到】
: L1 Cache不是想加倍就加倍的。
: 芯片面积、时序、功耗问题有很多。
|
s****x
发帖数: 42 | 34 尼玛，别话说一半，神神刀刀的。说说到底还有什么好处了？我就是不明白的之一
armv8的指令还是32位的。就是寄存器变成了64位，地址指针是64位的，但这和内存带
宽没必然关系。
通常应用很少会需要处理64位数据。除非是高精度的科学计算。
mobile cpu上现在还没有人做高精度计算吧。
gpu倒是常有128位的，那是经常把几条指令放在一起，还方便支持矢量运算
苹果a7的速度提升主要来自他们miceo-architecture的优化，和更大更快的cache吧
总有人以为32bit和64bit在
【在 r***i 的大作中提到】
: 总有人以为32bit和64bit在<4GB是没分别的，呵呵
|
d***a
发帖数: 13752 | 35 真想知道的话，这里有一个slides，只有26页，算是比较短的介绍了。
http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
【在 s****x 的大作中提到】
: 尼玛，别话说一半，神神刀刀的。说说到底还有什么好处了？我就是不明白的之一
: armv8的指令还是32位的。就是寄存器变成了64位，地址指针是64位的，但这和内存带
: 宽没必然关系。
: 通常应用很少会需要处理64位数据。除非是高精度的科学计算。
: mobile cpu上现在还没有人做高精度计算吧。
: gpu倒是常有128位的，那是经常把几条指令放在一起，还方便支持矢量运算
: 苹果a7的速度提升主要来自他们miceo-architecture的优化，和更大更快的cache吧
:
: 总有人以为32bit和64bit在
|
s****x
发帖数: 42 | 36 直接给讲解下呗，到底啥优势？
真想知道的话，这里有一个slides，只有26页，算是比较短的介绍了。http://www.arm.com/files/downloads/ARMv8_Arc........
【在 d***a 的大作中提到】
: 真想知道的话，这里有一个slides，只有26页，算是比较短的介绍了。
: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf
|
d***a
发帖数: 13752 | 37 一般用户真不需要知道那么多
如果想知道，得肯花时间才行
另外这版经常有些半懂不懂的人过来（不是说你，注意一下就知道了）
把技术问题当宗教问题来讨论，非常烦人
简单的讲解不会面面俱到，总有些粗糙之处，容易吸引那些人来
【在 s****x 的大作中提到】
: 直接给讲解下呗，到底啥优势？
:
: 真想知道的话，这里有一个slides，只有26页，算是比较短的介绍了。http://www.arm.com/files/downloads/ARMv8_Arc........
|
c****p
发帖数: 6474 | 38 architectural register数目和大小都各自翻倍了。
开始支持加密运算指令，不过非常有限。
加入了load-acquire和store-release以及改善了的barrier，对多线程的互斥操作的支
持好了点。
加入了各种针对64位数据操作的指令（主要是ALU和memory）；memory方面去掉了LDM和
STM，，以后相应指令的功能都由LDP/STP代替。
(继续)支持trusted zone（这块不太懂）
有更复杂的异常模型（这块也不懂）
加入了64K page的支持，好处是减少MMU walk（访存）的次数和层数。
支持最高48位的虚拟和物理地址（这个应该只是上限，实际的产品应该取决于实现）。
=====
是否支持乱序，多大的内存带宽，多大的L1和L2缓存，采用什么样的分支预测，使用多
少integer register和extended/SIMD register这些最实际决定CPU性能的参数都取决
于实现（即由产品的设计方决定）。
【在 s****x 的大作中提到】
: 直接给讲解下呗，到底啥优势？
:
: 真想知道的话，这里有一个slides，只有26页，算是比较短的介绍了。http://www.arm.com/files/downloads/ARMv8_Arc........
|
c****p
发帖数: 6474 | 39 哦，还忘了执行单元（ALU，FPU，Load Store Queue）的数目和流水线深度对性能也有
影响，这些也是取决于实现的。
【在 c****p 的大作中提到】
: architectural register数目和大小都各自翻倍了。
: 开始支持加密运算指令，不过非常有限。
: 加入了load-acquire和store-release以及改善了的barrier，对多线程的互斥操作的支
: 持好了点。
: 加入了各种针对64位数据操作的指令（主要是ALU和memory）；memory方面去掉了LDM和
: STM，，以后相应指令的功能都由LDP/STP代替。
: (继续)支持trusted zone（这块不太懂）
: 有更复杂的异常模型（这块也不懂）
: 加入了64K page的支持，好处是减少MMU walk（访存）的次数和层数。
: 支持最高48位的虚拟和物理地址（这个应该只是上限，实际的产品应该取决于实现）。
|
s****x
发帖数: 42 | 40 你说的翻译的都没错，但我想知道的是64位比32位带来哪些天然的性能优势（除了64位
计算，因为实际应用实在太少，就算强调计算的opencl里面双精度浮点都是optional
extension）
你说的大部分差异是armv8对比v7带来的。armv8的改变不只是64位。每一代都会加新指
令去掉几个不用的指令。
具体执行单元和流水线更是microarchitecture，和v8都没关系，苹果是arm的
artchitecture licensee。micro-arch怎么设计他们自己定。
我一点没怀疑apple a7性能的提高，就是没明白性能提高的哪部分是64位本身带来的。
苹果自己都没说是因为64位，所以才跑的快的不是？
哦，还忘了执行单元（ALU，FPU，Load Store Queue）的数目和流水线深度对性能也有
影响，这些也是取决于实现的。
【在 c****p 的大作中提到】
: 哦，还忘了执行单元（ALU，FPU，Load Store Queue）的数目和流水线深度对性能也有
: 影响，这些也是取决于实现的。
|
|
|
d***a
发帖数: 13752 | 41 说说我个人的看法。我觉得对大多数mobile程序来说，来自于ARMv8的影响，可能有三
个比较主要的因素。第一是寄存器数目的增加，这对性能会有可见的影响，也许在5-10
%上下。
第二是去掉了一些指令和指令集feature。ARMv7有一个的特点，所有的指令都支持
conditional execution。这个支持本身是好事，可以减少跳转指令的数目，但每条指
令都带这个feature，我觉得过头了，对流水线的实现会有比较大的负面影响。ARMv8改
成非常有限的支持，对流水线的实现效率应该是大有好处的。
第三是对浮点数的SIMD支持更好了。这对有浮点运算的程序有很大的影响。
"苹果自己都没说是因为64位，所以才跑的快的不是"，这是苹果的一贯风格，少提技术
上的事，就象苹果从来不宣传OS X是一个Unix系统。知道的人自然知道，不知道Unix为
何物的大妈用户，也不会因此就买苹果的计算机。
【在 s****x 的大作中提到】
: 你说的翻译的都没错，但我想知道的是64位比32位带来哪些天然的性能优势（除了64位
: 计算，因为实际应用实在太少，就算强调计算的opencl里面双精度浮点都是optional
: extension）
: 你说的大部分差异是armv8对比v7带来的。armv8的改变不只是64位。每一代都会加新指
: 令去掉几个不用的指令。
: 具体执行单元和流水线更是microarchitecture，和v8都没关系，苹果是arm的
: artchitecture licensee。micro-arch怎么设计他们自己定。
: 我一点没怀疑apple a7性能的提高，就是没明白性能提高的哪部分是64位本身带来的。
: 苹果自己都没说是因为64位，所以才跑的快的不是？
:
|
c****p
发帖数: 6474 | 42 你说得对，64位和性能提升关系至少没有一倍的体现
【在 s****x 的大作中提到】
: 你说的翻译的都没错，但我想知道的是64位比32位带来哪些天然的性能优势（除了64位
: 计算，因为实际应用实在太少，就算强调计算的opencl里面双精度浮点都是optional
: extension）
: 你说的大部分差异是armv8对比v7带来的。armv8的改变不只是64位。每一代都会加新指
: 令去掉几个不用的指令。
: 具体执行单元和流水线更是microarchitecture，和v8都没关系，苹果是arm的
: artchitecture licensee。micro-arch怎么设计他们自己定。
: 我一点没怀疑apple a7性能的提高，就是没明白性能提高的哪部分是64位本身带来的。
: 苹果自己都没说是因为64位，所以才跑的快的不是？
:
|
c****p
发帖数: 6474 | 43 conditional这个我有不同看法。。。
conditional code可以设成always，这样就不用查flag了。实际上多数指令的
condition code都是always。conditional false的指令从流水线上drop掉就好了。
而且支持V8 ISA的核一般都要向下兼容，所以conditional code这个地该实现的还是都
得实现，只能说跑v8指令集的程序可能会因此受益，但是CPU实现上在condition code
这个地方改进不大。
10
【在 d***a 的大作中提到】
: 说说我个人的看法。我觉得对大多数mobile程序来说，来自于ARMv8的影响，可能有三
: 个比较主要的因素。第一是寄存器数目的增加，这对性能会有可见的影响，也许在5-10
: %上下。
: 第二是去掉了一些指令和指令集feature。ARMv7有一个的特点，所有的指令都支持
: conditional execution。这个支持本身是好事，可以减少跳转指令的数目，但每条指
: 令都带这个feature，我觉得过头了，对流水线的实现会有比较大的负面影响。ARMv8改
: 成非常有限的支持，对流水线的实现效率应该是大有好处的。
: 第三是对浮点数的SIMD支持更好了。这对有浮点运算的程序有很大的影响。
: "苹果自己都没说是因为64位，所以才跑的快的不是"，这是苹果的一贯风格，少提技术
: 上的事，就象苹果从来不宣传OS X是一个Unix系统。知道的人自然知道，不知道Unix为
|
d***a
发帖数: 13752 | 44 这个...我不明白你说的“conditional code可以设成always”是什么意思。
下面是ARM汇编的例子:
cmp r0, r1 ; compare r0 and r1
strgt r0, [r2] ; if r0 > r1, save it to [r2]
strle r1, [r2] ; if r0 <= r1, save it to [r2]
也许你说的是让编译器只用str，不用strgt和strle? 可是不管编译器用不用，设计流
水线的时候还得支持，硬件复杂度还是在那里。
code
【在 c****p 的大作中提到】
: conditional这个我有不同看法。。。
: conditional code可以设成always，这样就不用查flag了。实际上多数指令的
: condition code都是always。conditional false的指令从流水线上drop掉就好了。
: 而且支持V8 ISA的核一般都要向下兼容，所以conditional code这个地该实现的还是都
: 得实现，只能说跑v8指令集的程序可能会因此受益，但是CPU实现上在condition code
: 这个地方改进不大。
:
: 10
|
c****p
发帖数: 6474 | 45 这就是我的point啊。。。。只要v8没有完全取消conditional，那硬件就得包括
conditional check。。。
【在 d***a 的大作中提到】
: 这个...我不明白你说的“conditional code可以设成always”是什么意思。
: 下面是ARM汇编的例子:
: cmp r0, r1 ; compare r0 and r1
: strgt r0, [r2] ; if r0 > r1, save it to [r2]
: strle r1, [r2] ; if r0 <= r1, save it to [r2]
: 也许你说的是让编译器只用str，不用strgt和strle? 可是不管编译器用不用，设计流
: 水线的时候还得支持，硬件复杂度还是在那里。
:
: code
|
d***a
发帖数: 13752 | 46 Conditional execution在低端处理器中并不难做。但在乱序执行的高性能处理器中，
要对每一条指令都做，硬件的复杂度会增加不少。ARMv8只有三种指令有这个feature，
实现起来就比ARMv7容易多了。
【在 c****p 的大作中提到】
: 这就是我的point啊。。。。只要v8没有完全取消conditional，那硬件就得包括
: conditional check。。。
|
c****p
发帖数: 6474 | 47 该做的还是得做。。因为即使是64位核也得向下兼容（因为至少第一和第二代64位CPU
不可能只跑v8的应用的），所以这个东西免不了。
乱序执行的CPU解决这个问题也不是很困难，就是比较浪费流水线的slot，但是并不用
像分支指令那样一旦预测错误就得清空流水线。
【在 d***a 的大作中提到】
: Conditional execution在低端处理器中并不难做。但在乱序执行的高性能处理器中，
: 要对每一条指令都做，硬件的复杂度会增加不少。ARMv8只有三种指令有这个feature，
: 实现起来就比ARMv7容易多了。
|
d***a
发帖数: 13752 | 48 ARM的做法不是这样。A64的指令集是重新设计的，指令格式都有变化，解码是A64和A32
各有一套解码器。
比较浪费流水线的slot...这就是比较大的性能问题了。那上ARMv8容易有性能上的提高
，有什么奇怪的呢？
ARM架构，上四核之间应该先上64-bit，从技术上说是很明显的了，虽然宣传上没有四
核那么好听。
CPU
【在 c****p 的大作中提到】
: 该做的还是得做。。因为即使是64位核也得向下兼容（因为至少第一和第二代64位CPU
: 不可能只跑v8的应用的），所以这个东西免不了。
: 乱序执行的CPU解决这个问题也不是很困难，就是比较浪费流水线的slot，但是并不用
: 像分支指令那样一旦预测错误就得清空流水线。
|
c****p
发帖数: 6474 | 49 译码器是分开（实际上应该也只有译码器是分开的）的，但是从乱序开始就必须合用流
水线了（不然太浪费），所以执行单元的流水线上还是要带conditional check的，不
论ISA和指令实际的condition code。所以，因为向下兼容的原因，硬件实现上并不因
为v8用了更少的conditional code而简化了设计。
v8减少了conditional code的种类，但是实际编译出来的binary中的conditional指令
“数目”是否比v7少呢。。。你前面举的例子，v8下应该用什么样的指令来避免
conditional code呢？
抛开conditional code部分不说。其实我觉得ARM现在这个样子主要是因为ARM的厂商为
了忽悠消费者打核战争都没有时间和资源安心做ARM微架构的优化。因为手机市场基本
都是ARM的盘子，做好做坏也都是ARM的U，所以ARM大概也没兴趣推动v7的架构优化。—
—我甚至都不觉得v8做为手机核心是必要的；堆核其实也不是必要的，但是确实好听；
Apple的A7双核一出，才让大家看到架构优化的必要之处——我其实更好奇苹果的微架
构是咋搞的（尤其是针对软件特性做了哪些优化），v8本身倒没啥看点。只是5S啥都泄
了只有64位核没泄这个事儿挺有意思的（仔细想来也不算太奇怪，因为供应链上不太可
能知道CPU的太具体的东西）。
ARM出v8的必然性是因为v8是冲着挖intel的服务器墙角去的。我知道有为数不多的几家
是打算明年出v8服务器核的，结果大家都没想到先在A7上开了花。
A32
【在 d***a 的大作中提到】
: ARM的做法不是这样。A64的指令集是重新设计的，指令格式都有变化，解码是A64和A32
: 各有一套解码器。
: 比较浪费流水线的slot...这就是比较大的性能问题了。那上ARMv8容易有性能上的提高
: ，有什么奇怪的呢？
: ARM架构，上四核之间应该先上64-bit，从技术上说是很明显的了，虽然宣传上没有四
: 核那么好听。
:
: CPU
|
d***a
发帖数: 13752 | 50 那是低端流水线的做法吧。高性能流水线中，指令集大量使用conditional
execution（CE）是一种负担。ARMv8 A64只让少数指令用，这样可以真
正地实现CE。至于A32中用了CE的指令，可以把CE转换成branch
prediction。也就是说，流水线设计按A64来优化。至于A32中的CE，就让
它有一些性能上的损失吧。
CE在实际中很有用，适当支持可以有效地减少跳转指令的数目。编译器应该
尽可能地使用，而不是尽少地使用。前提条件是流水线设计中要有真正意义
的CE，这又要求指令集中支持CE的指令相当较少。这才是正常的做法，
x64上就是这样做的。
ARM架构和x86架构一样，原本是为低端市场设计的，当时大概从没想过速度
会上GHz。x86采用内部翻译成micro-op的做法，ARM改动指令集，都是为
了设计高性能流水线的需要。我觉得并不是厂商不愿意花精力做微架构，
确实是原来的ARM指令集已经不适应现在的需求了。
【在 c****p 的大作中提到】
: 译码器是分开（实际上应该也只有译码器是分开的）的，但是从乱序开始就必须合用流
: 水线了（不然太浪费），所以执行单元的流水线上还是要带conditional check的，不
: 论ISA和指令实际的condition code。所以，因为向下兼容的原因，硬件实现上并不因
: 为v8用了更少的conditional code而简化了设计。
: v8减少了conditional code的种类，但是实际编译出来的binary中的conditional指令
: “数目”是否比v7少呢。。。你前面举的例子，v8下应该用什么样的指令来避免
: conditional code呢？
: 抛开conditional code部分不说。其实我觉得ARM现在这个样子主要是因为ARM的厂商为
: 了忽悠消费者打核战争都没有时间和资源安心做ARM微架构的优化。因为手机市场基本
: 都是ARM的盘子，做好做坏也都是ARM的U，所以ARM大概也没兴趣推动v7的架构优化。—
|
|
|
d***a
发帖数: 13752 | 51 对一般的手机用户来说，ARMv8和四核大概都不重要，但二选一的话，
还是ARMv8好一些。在5S上比较明显的相机应用，图像处理比以前快
多了。对一些power user来说还是很有用的。
苹果的微架构，我猜流水线结构可能并没有太大的变化，说不定结构
上还精简了...我也是随口猜猜，按常理来说，设计师不愿意同时做
两个方面的大改动。
...
：抛开conditional code部分不说。其实我觉得ARM现在这个样子主要是
：因为ARM的厂商为了忽悠消费者打核战争都没有时间和资源安心做ARM微架
：构的优化。因为手机市场基本都是ARM的盘子，做好做坏也都是ARM的U，
：所以ARM大概也没兴趣推动v7的架构优化。——我甚至都不觉得v8做为手机
：核心是必要的；堆核其实也不是必要的，但是确实好听；Apple的A7双核
：一出，才让大家看到架构优化的必要之处——我其实更好奇苹果的微架构是
：咋搞的（尤其是针对软件特性做了哪些优化），v8本身倒没啥看点。只是
：5S啥泄了只有64位核没泄这个事儿挺有意思的（仔细想来也不算太奇怪，
：因为供应链上不太可能知道CPU的太具体的东西）。
【在 c****p 的大作中提到】
: 译码器是分开（实际上应该也只有译码器是分开的）的，但是从乱序开始就必须合用流
: 水线了（不然太浪费），所以执行单元的流水线上还是要带conditional check的，不
: 论ISA和指令实际的condition code。所以，因为向下兼容的原因，硬件实现上并不因
: 为v8用了更少的conditional code而简化了设计。
: v8减少了conditional code的种类，但是实际编译出来的binary中的conditional指令
: “数目”是否比v7少呢。。。你前面举的例子，v8下应该用什么样的指令来避免
: conditional code呢？
: 抛开conditional code部分不说。其实我觉得ARM现在这个样子主要是因为ARM的厂商为
: 了忽悠消费者打核战争都没有时间和资源安心做ARM微架构的优化。因为手机市场基本
: 都是ARM的盘子，做好做坏也都是ARM的U，所以ARM大概也没兴趣推动v7的架构优化。—
|
c****p
发帖数: 6474 | 52 所谓高性能流水线是如何解决CE问题的？
在“必须”兼容A32的，即A64应用圈还不完善的第一代和第二代处理器上强行牺牲A32
的性能不太合适吧？
ARM的指令其实也在uop化。。很多宏指令也是被拆开了执行的。RISC/CISC的分野到了
现在已经不是那么明显了。
【在 d***a 的大作中提到】
: 那是低端流水线的做法吧。高性能流水线中，指令集大量使用conditional
: execution（CE）是一种负担。ARMv8 A64只让少数指令用，这样可以真
: 正地实现CE。至于A32中用了CE的指令，可以把CE转换成branch
: prediction。也就是说，流水线设计按A64来优化。至于A32中的CE，就让
: 它有一些性能上的损失吧。
: CE在实际中很有用，适当支持可以有效地减少跳转指令的数目。编译器应该
: 尽可能地使用，而不是尽少地使用。前提条件是流水线设计中要有真正意义
: 的CE，这又要求指令集中支持CE的指令相当较少。这才是正常的做法，
: x64上就是这样做的。
: ARM架构和x86架构一样，原本是为低端市场设计的，当时大概从没想过速度
|
c****p
发帖数: 6474 | 53 我比较恶毒地想可能好多v8的功能A7都没有。
考虑到苹果强调单线程应用性能和不用cache coherence的应用场景，
比如load-acquire和store-release，cache snoop这些东西可能都不用实现。
再深一点，既然连编译器都捏在苹果手里，连对有些指令的支持都不用实现。。
【在 d***a 的大作中提到】
: 对一般的手机用户来说，ARMv8和四核大概都不重要，但二选一的话，
: 还是ARMv8好一些。在5S上比较明显的相机应用，图像处理比以前快
: 多了。对一些power user来说还是很有用的。
: 苹果的微架构，我猜流水线结构可能并没有太大的变化，说不定结构
: 上还精简了...我也是随口猜猜，按常理来说，设计师不愿意同时做
: 两个方面的大改动。
:
: ...
: ：抛开conditional code部分不说。其实我觉得ARM现在这个样子主要是
: ：因为ARM的厂商为了忽悠消费者打核战争都没有时间和资源安心做ARM微架
|
s****x
发帖数: 42 | 54 市场上arm的architecture licensee 没几家。大部分厂商直接licensee arm的core 包
括三星，nvidia，山寨之王联发科等。qcom 和apple之类自己做core的，实际和arm有
竞争关系。apple还好，soc不外卖，但他首个推出64位还是给arm不少压力。arm自己的
implementation至少得和苹果平起平坐才说得过去。
所以arm core是有动力去优化的，不是别人来优化，是arm自己，三星跑分跑不过apple
，最终找的不是自己的芯片部门，而是来找arm的cpu部门
译码器是分开（实际上应该也只有译码器是分开的）的，但是从乱序开始就必须合用流
水线了（不然太浪费），所以执行单元的流水线上还是要带conditional check的，不
论ISA........
【在 c****p 的大作中提到】
: 译码器是分开（实际上应该也只有译码器是分开的）的，但是从乱序开始就必须合用流
: 水线了（不然太浪费），所以执行单元的流水线上还是要带conditional check的，不
: 论ISA和指令实际的condition code。所以，因为向下兼容的原因，硬件实现上并不因
: 为v8用了更少的conditional code而简化了设计。
: v8减少了conditional code的种类，但是实际编译出来的binary中的conditional指令
: “数目”是否比v7少呢。。。你前面举的例子，v8下应该用什么样的指令来避免
: conditional code呢？
: 抛开conditional code部分不说。其实我觉得ARM现在这个样子主要是因为ARM的厂商为
: 了忽悠消费者打核战争都没有时间和资源安心做ARM微架构的优化。因为手机市场基本
: 都是ARM的盘子，做好做坏也都是ARM的U，所以ARM大概也没兴趣推动v7的架构优化。—
|
s****x
发帖数: 42 | 55 不对吧，muti core 直接怎么可能不实现cache coherent？除非你没有cache
我比较恶毒地想可能好多v8的功能A7都没有。考虑到苹果强调单线程应用性能和不用
cache coherence的应用场景，比如load-acquire和store-release........
【在 c****p 的大作中提到】
: 我比较恶毒地想可能好多v8的功能A7都没有。
: 考虑到苹果强调单线程应用性能和不用cache coherence的应用场景，
: 比如load-acquire和store-release，cache snoop这些东西可能都不用实现。
: 再深一点，既然连编译器都捏在苹果手里，连对有些指令的支持都不用实现。。
|
d***a
发帖数: 13752 | 56 大致上是这样，对应于condition register(CR)有专门的一组rename CR。
Conditionally executed的指令，会等待一个rename CR的结果，这个结果
出来后，指令才被发射出去。但一般只有少数类别的指令可以这样做，在指令
调度的时候，这样指令可以放到一个特殊的调度cluster里去等待。
但ARMv7很难用这样的做法，那意味rename CR要广播到所有等待执行的指令去，
增加的设计复杂度，不能justify性能上的一些提高。
【在 c****p 的大作中提到】
: 所谓高性能流水线是如何解决CE问题的？
: 在“必须”兼容A32的，即A64应用圈还不完善的第一代和第二代处理器上强行牺牲A32
: 的性能不太合适吧？
: ARM的指令其实也在uop化。。很多宏指令也是被拆开了执行的。RISC/CISC的分野到了
: 现在已经不是那么明显了。
|
d***a
发帖数: 13752 | 57 这个是过虑了。就算编译器在苹果手上，架不住编程员直接在C语言中
插入汇编语言。
实现一个新的ISA是个技术活，有难度无风险，踏踏实实地做就能做
出来，苹果没有理由干这事。
【在 c****p 的大作中提到】
: 我比较恶毒地想可能好多v8的功能A7都没有。
: 考虑到苹果强调单线程应用性能和不用cache coherence的应用场景，
: 比如load-acquire和store-release，cache snoop这些东西可能都不用实现。
: 再深一点，既然连编译器都捏在苹果手里，连对有些指令的支持都不用实现。。
|
d***a
发帖数: 13752 | 58 等ARM做？在做处理器的几个公司里，做高性能流水线经验最少的就数ARM了。
苹果挖了AMD的人来做，Qualcomm挖了IBM的人来做。三星最近把AMD
做处理器的人挖走一小半，其用心昭然若揭。
apple
【在 s****x 的大作中提到】
: 市场上arm的architecture licensee 没几家。大部分厂商直接licensee arm的core 包
: 括三星，nvidia，山寨之王联发科等。qcom 和apple之类自己做core的，实际和arm有
: 竞争关系。apple还好，soc不外卖，但他首个推出64位还是给arm不少压力。arm自己的
: implementation至少得和苹果平起平坐才说得过去。
: 所以arm core是有动力去优化的，不是别人来优化，是arm自己，三星跑分跑不过apple
: ，最终找的不是自己的芯片部门，而是来找arm的cpu部门
:
: 译码器是分开（实际上应该也只有译码器是分开的）的，但是从乱序开始就必须合用流
: 水线了（不然太浪费），所以执行单元的流水线上还是要带conditional check的，不
: 论ISA........
|
s****x
发帖数: 42 | 59 呵呵，三爽虽然现在用arm core，但他也是architecture licencee。所以一切皆有可能
等ARM做？在做处理器的几个公司里，做高性能流水线经验最少的就数ARM了。苹果挖了
AMD的人来做，Qualcomm挖了IBM的人来做。三星最近把AMD做处理器的人挖走一小半，
其........
【在 d***a 的大作中提到】
: 等ARM做？在做处理器的几个公司里，做高性能流水线经验最少的就数ARM了。
: 苹果挖了AMD的人来做，Qualcomm挖了IBM的人来做。三星最近把AMD
: 做处理器的人挖走一小半，其用心昭然若揭。
:
: apple
|
g*******t
发帖数: 7704 | 60 Intel在不开发arm cpu，就真没希望了， amd的人全转arm |
|
|
s********i
发帖数: 17328 | 61 一不留神说了句实话而已。其实没有必要说实话，联合起来忽悠用户赚钱才是正道。 |
s****x
发帖数: 42 | 62 不用想intel了，他干嘛都没用了。
不是技术问题，而是市场问题，intel的高margin垄断型business model已经被破坏了,
当年pc大家喝汤，就intel吃肉。
现在是群雄并起逐鹿中原的年代，人人都可以造自己的cpu，做intel。一台手机付给
arm才几个钱。
封建时代结束了，现在民国了。袁世凯复辟是没可能成功的。
Intel在不开发arm cpu，就真没希望了， amd的人全转arm
【在 g*******t 的大作中提到】
: Intel在不开发arm cpu，就真没希望了， amd的人全转arm
|
c****p
发帖数: 6474 | 63 这个实现实际上就相当于增加了一个或者若干个register source而已。
CR组本来也不会很大。
只是check source register的逻辑的规模变大而已，复杂度嘛……
而且实际运行的时候，多数指令的condition code都是always，
是不需要检查flags的。
【在 d***a 的大作中提到】
: 大致上是这样，对应于condition register(CR)有专门的一组rename CR。
: Conditionally executed的指令，会等待一个rename CR的结果，这个结果
: 出来后，指令才被发射出去。但一般只有少数类别的指令可以这样做，在指令
: 调度的时候，这样指令可以放到一个特殊的调度cluster里去等待。
: 但ARMv7很难用这样的做法，那意味rename CR要广播到所有等待执行的指令去，
: 增加的设计复杂度，不能justify性能上的一些提高。
|
c****p
发帖数: 6474 | 64 三星搞自己的核简直是一定的。不用说别的，下一款手机用的64位核就肯定不可能直接
用A53或者A57（这俩核出来的时间太晚，架构也未必适应移动平台）。
64位核不管是服务器用还是移动平台用，各家应该早都开搞了，只不过要么保密要么不
想纸上谈兵才没放话出来。
这次苹果的A7出来，才逼得三星高通这样的不得不放个风出来打消投资者的疑虑。
所以并不是苹果先行，其他人跟风；而是大家都在做，只不过苹果出来得快一些。
可能
【在 s****x 的大作中提到】
: 呵呵，三爽虽然现在用arm core，但他也是architecture licencee。所以一切皆有可能
:
: 等ARM做？在做处理器的几个公司里，做高性能流水线经验最少的就数ARM了。苹果挖了
: AMD的人来做，Qualcomm挖了IBM的人来做。三星最近把AMD做处理器的人挖走一小半，
: 其........
|
d***a
发帖数: 13752 | 65 你这还是在讨论低端处理器流水线。
Rename CR本来就有，就算处理器不支持conditional execution也有。
在高性能流水线中，如果每条指令都真实地支持conditional execution，
rename CR就得广播到每条处于等待状态下的指令里去，这才是问题所在。
【在 c****p 的大作中提到】
: 这个实现实际上就相当于增加了一个或者若干个register source而已。
: CR组本来也不会很大。
: 只是check source register的逻辑的规模变大而已，复杂度嘛……
: 而且实际运行的时候，多数指令的condition code都是always，
: 是不需要检查flags的。
|
c****p
发帖数: 6474 | 66 所以……还是增加了source register check而已？每个op的schedule state多5*N位，
外加广播的routing。
v7全支持CE比v8小部分支持CE的面积大概要大多少？
【在 d***a 的大作中提到】
: 你这还是在讨论低端处理器流水线。
: Rename CR本来就有，就算处理器不支持conditional execution也有。
: 在高性能流水线中，如果每条指令都真实地支持conditional execution，
: rename CR就得广播到每条处于等待状态下的指令里去，这才是问题所在。
|
d***a
发帖数: 13752 | 67 而已?!
高性能流水线设计的思路是不一样的。这是为什么ARM做不过苹果...
或者说做不过AMD的设计师。
【在 c****p 的大作中提到】
: 所以……还是增加了source register check而已？每个op的schedule state多5*N位，
: 外加广播的routing。
: v7全支持CE比v8小部分支持CE的面积大概要大多少？
|
c****p
发帖数: 6474 | 68 我还是想看看两者差别有多大。。
除了CE之外，高性能流水线和低性能流水线还有啥代表性的区别？
【在 d***a 的大作中提到】
: 而已?!
: 高性能流水线设计的思路是不一样的。这是为什么ARM做不过苹果...
: 或者说做不过AMD的设计师。
|
d***a
发帖数: 13752 | 69 多发，乱序，大指令窗口。Cortex-A9那样的不算。
比如说Haswell，一个时钟周期可以发射八条指令。
其实CE是其中一个比较小的问题。ARMv7的CE设计不好，
是因为它会搞乱多发的效率。
【在 c****p 的大作中提到】
: 我还是想看看两者差别有多大。。
: 除了CE之外，高性能流水线和低性能流水线还有啥代表性的区别？
|
c****p
发帖数: 6474 | 70 这三样不都是super scalar的经典要素么。。
你说的发射是指译码器到调度那段还是调序到执行单元那段？
大指令窗口一般要多大？128？
【在 d***a 的大作中提到】
: 多发，乱序，大指令窗口。Cortex-A9那样的不算。
: 比如说Haswell，一个时钟周期可以发射八条指令。
: 其实CE是其中一个比较小的问题。ARMv7的CE设计不好，
: 是因为它会搞乱多发的效率。
|
|
|
d***a
发帖数: 13752 | 71 ARM做过这些?! 光知道概念和名词是不行的。
【在 c****p 的大作中提到】
: 这三样不都是super scalar的经典要素么。。
: 你说的发射是指译码器到调度那段还是调序到执行单元那段？
: 大指令窗口一般要多大？128？
|
c****p
发帖数: 6474 | 72 没做是因为面向低端U呗。。
苹果A7你有啥好料爆不。。。有OoO是肯定的，其他的呢。。。
【在 d***a 的大作中提到】
: ARM做过这些?! 光知道概念和名词是不行的。
|
d***a
发帖数: 13752 | 73 苹果一向是黑箱做业...保密做得还真不错，换别的公司总会有些设计上的东西漏出来。
【在 c****p 的大作中提到】
: 没做是因为面向低端U呗。。
: 苹果A7你有啥好料爆不。。。有OoO是肯定的，其他的呢。。。
|
