asm、bin、elf都不能说明问题，但是比较它们在工程上有意义，嵌入的话文件大小还是个关键问题。
ARM不是严格的RISC，它有很多CISC的特性，stmdb这些就是典型例子，需记住CISC的哲学是：CPU designers tried to make instructions that would do as much work as possible，而RISC刚相反。所以ARM宣传时只说“有哪些哪些RISC特性”，人家没说这是纯RISC处理器。
最后，我不知道你做这种关于代码密度的比较有什么实际意义。 这是个很学术的比较，你应该比较obj
asm、bin、elf都不能说明问题，但是比较它们在工程上有意义，嵌入的话 ...
NalaGinrut 发表于 2010-02-07 11:03 http://linux.chinaunix.net/bbs/images/common/back.gif
从嵌入式方面来讲，代码密度大 ---> 就意味这flash 容量可以降下来-----> 成本有所降低 --------> 毛利率增加
所以，在这种情况下只能看binary的大小。 从嵌入式方面来讲，代码密度大 ---> 就意味这flash 容量可以降下来-----> 成本有所降低 -------- ...
rocky1972 发表于 2010-02-07 13:07 http://linux.chinaunix.net/bbs/images/common/back.gif
我明白你的想法，但是这个问题不能做这么简单的比较，代码密度涉及的问题还很多。
如果是工程上的研究，还需要考虑具体编码，以及编译优化的问题，你应该拿几个实际的有点规模的项目的编译结果来做比较，并不是hello world的代码密度决定所有的代码密度。 我明白你的想法，但是这个问题不能做这么简单的比较，代码密度涉及的问题还很多。
如果是工程上的 ...
NalaGinrut 发表于 2010-02-08 09:12 http://linux.chinaunix.net/bbs/images/common/back.gif
>>>>我明白你的想法，但是这个问题不能做这么简单的比较，代码密度涉及的问题还很多。
请教一下， 具体还有哪些方面需要考虑？
>>>如果是工程上的研究，还需要考虑具体编码，以及编译优化的问题，你应该拿几个实际的有点规模的项目的编译结果来做比较，并不是hello world的代码密度决定所有的代码密度。
一样的C代码，一个用arm toolchain 编译； 一个用mips toolchain 来编译, 优化选项都一样。请教一下除此之外，还需要考虑哪些方面呢？ 应该用较大的工程来评估。总共才那么几句代码，出入栈的开销都比真正有用的代码大。如果是对这种hellworld要比较大小，应该排除stdlib和crt的影响。链接的时候用-nostdlib -e _main来指定入口，不要将crt链接进去。另外binary文件不能真实反映代码的大小，因为有些空间是用来填充内存的。
我今天用sqlite试了一下，发现我当初arm和mips的判断是错误的
D:\sqlite3>ccmips -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o mips.o
D:\sqlite3>ccarm -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o arm.o
D:\sqlite3>ccppc -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o ppc.o
D:\sqlite3>sizearm *.o
text data bss dec hex filename
356532 2936 692360160 57ee0 arm.o
427808 2944 704431456 69560 mips.o
413624 2944 676417244 65ddc ppc.o
mips用-mips1，-mips2，-mips3，-mips5分别编译的结果如下：
D:\sqlite3>ccmips -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o mips1.o -mips32 -mips1
D:\sqlite3>ccmips -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o mips2.o -mips32 -mips2
D:\sqlite3>ccmips -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o mips3.o -mips32 -mips3
D:\sqlite3>ccmips -w -c sqlite3.c -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_HOMEGROWN_RECURSIVE_MUTEX -O2 -o mips5.o -mips32 -mips5
402320 2944 704405968 631d0 mips1.o
401552 2944 704405200 62ed0 mips2.o
401264 2944 704404912 62db0 mips3.o
398496 2944 704402144 622e0 mips5.o 现在已经没有纯种了，都是杂种:lolMIPS，除了跟国家的事业联系在了一起，别的还真没什么特别的。现在MIPS也是杂种了。 应该用较大的工程来评估。总共才那么几句代码，出入栈的开销都比真正有用的代码大。如果是对这种hellworld要 ...
lllaaa 发表于 2010-02-08 12:52 http://linux.chinaunix.net/bbs/images/common/back.gif
>>>>>>应该用较大的工程来评估。总共才那么几句代码，出入栈的开销都比真正有用的代码大。如果是对这种hellworld要比较大小，应该排除stdlib和crt的影响。链接的时候用-nostdlib -e _main来指定入口，不要将crt链接进去。另外binary文件不能真实反映代码的大小，因为有些空间是用来填充内存的。
我说说我的理解和感受：
1： 一个加法虽然简单，但是这足可以用反汇编的代码来比较代码密度了。大的工程也是有一个个小的函数实现的，小函数的差异会通过大的工程来放大。正所谓一粒沙子一个天堂。
2： mips的代码密度小于arm，是因为除了出入栈，还有多余加的延时槽。
3：编译内核的时，加入ext3文件系统支持，看built-in.o也能看出arm和mips的差别来 1）根据我的实验结果，我不否认同样的代码arm编译出来比mips小
2）源代码太短小体现不了代码密度。比如mips和arm出入栈有差异，在加法运算指令差异不大的情况下，出入栈的差异就占了代码差异很大一部分。如果代码规模大一些，出入栈占的比例就比较小。这样才能体现平均水平。又比如arm没有除法指令，而mips有。arm只能通过一大堆代码来实现除法。如果你例子里的运算是除法，而仅仅用一个运算来评判的话，你会得出mips密度比arm大的结论。
3）mips的delay slot并不是造成浪费的原因。delay slot里可以填充其他指令，只要他不使用前一条指令的结果就ok。你编译的时候由于没有打开优化，所以编译器没有做指令的调度。实际上delay slot在某些情况下可以大大提升速度。比如一个for循环，循环体结束的时候跳回前面。那条跳转指令的delay slot里面可以放一条将循环变量累加的指令。
aaa.c是我修改了你的代码，把加法换成除法
D:\sqlite3>ccarm -O2 -nostdlibaaa.c -Wl,-( -e main -LE:\Tornado2.2ARM\target\l
ib\arm\ARMARCH5\common\ -lgcc -Wl,-) -o arm.elf
D:\sqlite3>ccmips -O2 -nostdlib aaa.c -Wl,-( -e main -LE:\tornado2.2_mips\target
\lib\mips\MIPS32\sfcommon\ -lgcc-Wl,-) -o mips.elf
D:\sqlite3>ccppc -O2 -nostdlib aaa.c -Wl,-( -e main -LE:\tornado_for_ppc\target\
lib\ppc\PPC603\common\ -lgcc -Wl,-) -o ppc.elf
D:\sqlite3>sizearm *.elf
text data bss dec hex filename
268 2 2 272 110 arm.elf 可以看到除法的时候arm使用的空间比mips大
112 0 0 112 70 mips.elf
88 0 0 88 58 ppc.elf#include <stdio.h>
#include <stdlib.h>
int foo(int a, int b)
{
return (a / b);
}
int dumm(int a, int b ,int c , int d,int e)
{
return (a + b + c +d);
}
int main(int argc ,char ** argv)
{
int c;
c = foo(1,2);
c = dumm(1,2,3,4,5);
return c;
}
1）根据我的实验结果，我不否认同样的代码arm编译出来比mips小
2）源代码太短小体现不了代码密度。比如mip ...
lllaaa 发表于 2010-02-11 13:36 http://linux.chinaunix.net/bbs/images/common/back.gif
哈哈，MIPS的FAE就举得除法这个例子。。。。。。。。。。。。。
页:
1
[2]