Mips的代码密度没有ARM大

lllaaa

可能这个例子比较简单无法说明情况。但是根据我的实验。thumb<mips<arm<ppc

华为的以太网交换机三种cpu都用到了。有一次我比较了用ppc、arm、mips三款设备的obj文件，编译完后使用size命令来统计代码段大小。得出的结论是mips<arm<ppc。之后重新用thumb指令集编译全套代码（1G左右），得出thumb<mips<arm<ppc的结论。现在回想起来可能不同设备使用特性不一样有一定的影响。可以回头再验证一下。但实际这个大小跟编译器的质量有关。即使是vxworks 5.5里面gcc 2.95+风河的一堆修补，对三种平台的支持程度也是不一样的。

另外，mips编译填充的nop我认为还是没有打开编译器优化选项。delay slot的话可以不用填充nop，lz编译的时候用的默认优化，那就直接填充nop了事了。

另外看二进制大小可以不用这么麻烦。objdump ，readelf，size都可以看。

lz试一试编译http://www.sqlite.org/sqlite-amalgamation-3_6_22.zip比较一下。我周一回头也再比较一下。

lllaaa

底层驱动，特别是固件的代码，应该是看binary的大小吧
rocky1972 发表于 2010-02-06 21:01

你的那个例子是看的最终链接后的binary，我认为不能反映纯粹的代码编译结果，因为已经和crt链接到一起了。其实你的目的只想比较函数而已。从反汇编的结果来看，arm在函数头用1条指令就可以把一堆寄存器压栈，而mips要调整栈后慢慢赋值。由于你的函数非常简单仅仅是加法运算，这部分入栈代码的差异相对来说就占了更大的比例。因此后面我建议你用sqlite的代码编译后用binutils里面的size命令来看看text段大小的差异。

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

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. }
    

复制代码