Mips的代码密度没有ARM大

NalaGinrut

这是个很学术的比较，你应该比较obj
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处理器。

最后，我不知道你做这种关于代码密度的比较有什么实际意义。

rocky1972

这是个很学术的比较，你应该比较obj
asm、bin、elf都不能说明问题，但是比较它们在工程上有意义，嵌入的话 ...
NalaGinrut 发表于 2010-02-07 11:03

    从嵌入式方面来讲，代码密度大 ---> 就意味这flash 容量可以降下来-----> 成本有所降低 --------> 毛利率增加
    所以，在这种情况下只能看binary的大小。

NalaGinrut

从嵌入式方面来讲，代码密度大 ---> 就意味这flash 容量可以降下来-----> 成本有所降低 -------- ...
rocky1972 发表于 2010-02-07 13:07

我明白你的想法，但是这个问题不能做这么简单的比较，代码密度涉及的问题还很多。
如果是工程上的研究，还需要考虑具体编码，以及编译优化的问题，你应该拿几个实际的有点规模的项目的编译结果来做比较，并不是hello world的代码密度决定所有的代码密度。

rocky1972

我明白你的想法，但是这个问题不能做这么简单的比较，代码密度涉及的问题还很多。
如果是工程上的 ...
NalaGinrut 发表于 2010-02-08 09:12

>>>>我明白你的想法，但是这个问题不能做这么简单的比较，代码密度涉及的问题还很多。
请教一下， 具体还有哪些方面需要考虑？



>>>如果是工程上的研究，还需要考虑具体编码，以及编译优化的问题，你应该拿几个实际的有点规模的项目的编译结果来做比较，并不是hello world的代码密度决定所有的代码密度。


一样的C代码，一个用arm toolchain 编译； 一个用mips toolchain 来编译, 优化选项都一样。请教一下除此之外，还需要考虑哪些方面呢？

lllaaa

应该用较大的工程来评估。总共才那么几句代码，出入栈的开销都比真正有用的代码大。如果是对这种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     692  360160   57ee0 arm.o
427808    2944     704  431456   69560 mips.o
413624    2944     676  417244   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     704  405968   631d0 mips1.o
401552    2944     704  405200   62ed0 mips2.o
401264    2944     704  404912   62db0 mips3.o
398496    2944     704  402144   622e0 mips5.o

prolj

现在已经没有纯种了，都是杂种  MIPS，除了跟国家的事业联系在了一起，别的还真没什么特别的。现在MIPS也是杂种了。

rocky1972

应该用较大的工程来评估。总共才那么几句代码，出入栈的开销都比真正有用的代码大。如果是对这种hellworld要 ...
lllaaa 发表于 2010-02-08 12:52

    >>>>>>应该用较大的工程来评估。总共才那么几句代码，出入栈的开销都比真正有用的代码大。如果是对这种hellworld要比较大小，应该排除stdlib和crt的影响。链接的时候用-nostdlib -e _main来指定入口，不要将crt链接进去。另外binary文件不能真实反映代码的大小，因为有些空间是用来填充内存的。

    我说说我的理解和感受：
1： 一个加法虽然简单，但是这足可以用反汇编的代码来比较代码密度了。大的工程也是有一个个小的函数实现的，小函数的差异会通过大的工程来放大。正所谓一粒沙子一个天堂。
2： mips的代码密度小于arm，是因为除了出入栈，还有多余加的延时槽。

3：编译内核的时，加入ext3文件系统支持，看built-in.o也能看出arm和mips的差别来

lllaaa

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 -nostdlib  aaa.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

1. #include <stdio.h>
   
2. #include <stdlib.h>
   
3. 
   
4. int foo(int a, int b)
   
5. {
   
6. 
   
7. return (a / b);
   
8. }
   
9. int dumm(int a, int b ,int c , int d,int e)
   
10. {
    
11. 
    
12. return (a + b + c +d);
    
13. 
    
14. }
    
15. 
    
16. 
    
17. int main(int argc ,char ** argv)
    
18. {
    
19. 
    
20. 
    
21. int c;
    
22. 
    
23. c = foo(1,2);
    
24. c = dumm(1,2,3,4,5);
    
25. return c;
    
26. 
    
27. }
    

复制代码

rocky1972

1）根据我的实验结果，我不否认同样的代码arm编译出来比mips小
2）源代码太短小体现不了代码密度。比如mip ...
lllaaa 发表于 2010-02-11 13:36

    哈哈，MIPS的FAE就举得除法这个例子。。。。。。。。。。。。。