r******s
发帖数: 925 | 1 【 以下文字转载自 robotics 讨论区 】
发信人: robotics (机器人技术), 信区: robotics
标 题: 嵌入式编程问题
发信站: BBS 未名空间站 (Sun Jul 20 16:56:13 2008), 转信
通常涉及到real-time部分，一方面要考虑代码的可维护性，
一方面要考虑到系统的哦执行时间，大家觉得怎么取舍？
比方说要读写100个地址，如果用循环，每次循环要多运算好多东西
for (i=0; i <100; i++)
read[i] = *(*****+i);
但是要是用
read[0] = *(******00);
read[1] = *(******01);
会让代码很长不好维护
一般我是用后者的，即使只读10个地址（对系统影响很小）。
各位有没有什么其他的观点？
每一个小地方节约几个CPU周期，整个系统就会提高很大的效率。
或者，硬件升级很快，不用把代码搞得这么冗长？ |
D*******a
发帖数: 3688 | 2 循环部分可以用asm写吧
【在 r******s 的大作中提到】
: 【 以下文字转载自 robotics 讨论区 】
: 发信人: robotics (机器人技术), 信区: robotics
: 标 题: 嵌入式编程问题
: 发信站: BBS 未名空间站 (Sun Jul 20 16:56:13 2008), 转信
: 通常涉及到real-time部分，一方面要考虑代码的可维护性，
: 一方面要考虑到系统的哦执行时间，大家觉得怎么取舍？
: 比方说要读写100个地址，如果用循环，每次循环要多运算好多东西
: for (i=0; i <100; i++)
: read[i] = *(*****+i);
: 但是要是用
|
a****l
发帖数: 8211 | 3 I don't think the latter one will be faster. Larger code segment might be
slower for execution.
Save a few cycles here and there does NOT necessarily mean your system will
提高很大的效率. You must understand where the bottleneck is.
Real-time system is more about scheduling than making code faster.
【在 r******s 的大作中提到】
: 【 以下文字转载自 robotics 讨论区 】
: 发信人: robotics (机器人技术), 信区: robotics
: 标 题: 嵌入式编程问题
: 发信站: BBS 未名空间站 (Sun Jul 20 16:56:13 2008), 转信
: 通常涉及到real-time部分，一方面要考虑代码的可维护性，
: 一方面要考虑到系统的哦执行时间，大家觉得怎么取舍？
: 比方说要读写100个地址，如果用循环，每次循环要多运算好多东西
: for (i=0; i <100; i++)
: read[i] = *(*****+i);
: 但是要是用
|
r******s
发帖数: 925 | 4 schedule当然很重要，我是说应该保持一个什么样的嵌入式编程习惯
每个小地方都注意还是切实去寻找大大提高性能的地方，例如硬件更新或者你说的
schedule
就像生活中：是从小处节俭还是找更多的赚钱路子。
will
【在 a****l 的大作中提到】
: I don't think the latter one will be faster. Larger code segment might be
: slower for execution.
: Save a few cycles here and there does NOT necessarily mean your system will
: 提高很大的效率. You must understand where the bottleneck is.
: Real-time system is more about scheduling than making code faster.
|
r******s
发帖数: 925 | 5 可是我的asm不是利索，找时间再翻翻书，找找例子
【在 D*******a 的大作中提到】
: 循环部分可以用asm写吧
|
O*******d
发帖数: 20343 | 6 google "loop unrolling"
【在 r******s 的大作中提到】
: 可是我的asm不是利索，找时间再翻翻书，找找例子
|
h*******e
发帖数: 225 | 7 最重要的习惯是保持头脑清醒，知道自己应该干什么。
比如不知道循环会不会成为瓶颈，就做展开之类的末端优化，就是不清醒的表现。
【在 r******s 的大作中提到】
: schedule当然很重要，我是说应该保持一个什么样的嵌入式编程习惯
: 每个小地方都注意还是切实去寻找大大提高性能的地方，例如硬件更新或者你说的
: schedule
: 就像生活中：是从小处节俭还是找更多的赚钱路子。
:
: will
|
e******e
发帖数: 147 | 8 最好是搞清楚你使用的complier的特性。
ASM的效率是最高的，不过麻烦，可以用C/C++高级语言来做测试，
编一些测试代码，对照来调试，看看翻译的ASM是否高效，选择出适合你这个平台的编
程习惯。
如果使用时间足够长，你可以用C/C++编制出近乎ASM效率的程序。
要提高效率，必须在每一个细节处做改进，最后你才能获得足够的余量实现所谓“不可
能”完成的任务。
real-time system的效率还是非常重要的。。。 |
l******r
发帖数: 156 | 9 1. figure out where your memory is located and use DM.
2. figure out how big is your I$ and do loop unrolling. |
m********a
发帖数: 1312 | |
|
|
r******s
发帖数: 925 | 11 ；）多谢指教
【在 h*******e 的大作中提到】
: 最重要的习惯是保持头脑清醒，知道自己应该干什么。
: 比如不知道循环会不会成为瓶颈，就做展开之类的末端优化，就是不清醒的表现。
|
r******s
发帖数: 925 | 12 以前别人也是这样教我的，不过是我对细节地方钻研的不够透彻
【在 e******e 的大作中提到】
: 最好是搞清楚你使用的complier的特性。
: ASM的效率是最高的，不过麻烦，可以用C/C++高级语言来做测试，
: 编一些测试代码，对照来调试，看看翻译的ASM是否高效，选择出适合你这个平台的编
: 程习惯。
: 如果使用时间足够长，你可以用C/C++编制出近乎ASM效率的程序。
: 要提高效率，必须在每一个细节处做改进，最后你才能获得足够的余量实现所谓“不可
: 能”完成的任务。
: real-time system的效率还是非常重要的。。。
|
b******a
发帖数: 215 | 13 compiler的优化有时间好像也会有问题。
我以前用analog的 visual DSP在他自己的DSP上跑大规模的模拟程序，算法的核心就是
矩阵的LU变换。这个东西得C语言的算法已经很成熟了，但是在DSP上如果不做优化的话
，基本上不能用，速度太慢了。但是如果用comipler的优化选项打开，选择优化到最少
的运行时间，编译好的程序跑出来的结果总是不对，一个4x4的矩阵的LU分解都算不对
，不知道为什么。
后来就是自己手工写asm码，loop unrolling加上DSP支持的SIMD，速度差不多提高了20
多倍。
【在 e******e 的大作中提到】
: 最好是搞清楚你使用的complier的特性。
: ASM的效率是最高的，不过麻烦，可以用C/C++高级语言来做测试，
: 编一些测试代码，对照来调试，看看翻译的ASM是否高效，选择出适合你这个平台的编
: 程习惯。
: 如果使用时间足够长，你可以用C/C++编制出近乎ASM效率的程序。
: 要提高效率，必须在每一个细节处做改进，最后你才能获得足够的余量实现所谓“不可
: 能”完成的任务。
: real-time system的效率还是非常重要的。。。
|
e******e
发帖数: 147 | 14 不同开发平台的complier特性是不同的，特别是嵌入式系统，每个厂商水平不一，风格
不同，规则也不同。尽管基本的编译原理相同，但是细节处理上却非常不同。
要想开发好一个实时嵌入式系统，必须做到两点：第一，对你所使用的语言了解；第二
，对你所使用的平台的深入理解。
对照着你的高级语言代码，仔细研究编译后的list code，甚至是binary code，是成为
高手不可或缺的重要步骤。 |
r******s
发帖数: 925 | 15 牛，不过我还没法看懂list code和binary code
【在 e******e 的大作中提到】
: 不同开发平台的complier特性是不同的，特别是嵌入式系统，每个厂商水平不一，风格
: 不同，规则也不同。尽管基本的编译原理相同，但是细节处理上却非常不同。
: 要想开发好一个实时嵌入式系统，必须做到两点：第一，对你所使用的语言了解；第二
: ，对你所使用的平台的深入理解。
: 对照着你的高级语言代码，仔细研究编译后的list code，甚至是binary code，是成为
: 高手不可或缺的重要步骤。
|
r******s
发帖数: 925 | 16 都是高手啊
20
【在 b******a 的大作中提到】
: compiler的优化有时间好像也会有问题。
: 我以前用analog的 visual DSP在他自己的DSP上跑大规模的模拟程序，算法的核心就是
: 矩阵的LU变换。这个东西得C语言的算法已经很成熟了，但是在DSP上如果不做优化的话
: ，基本上不能用，速度太慢了。但是如果用comipler的优化选项打开，选择优化到最少
: 的运行时间，编译好的程序跑出来的结果总是不对，一个4x4的矩阵的LU分解都算不对
: ，不知道为什么。
: 后来就是自己手工写asm码，loop unrolling加上DSP支持的SIMD，速度差不多提高了20
: 多倍。
|
k****f
发帖数: 3794 | 17 嵌入式的cpu一般比较简单的，手写汇编还是可以的。
我曾经在intel cpu上手写过汇编，调用mmx，sse指令加速一个算法，
mmd，比直接用c编译出来差不少的
20
【在 b******a 的大作中提到】
: compiler的优化有时间好像也会有问题。
: 我以前用analog的 visual DSP在他自己的DSP上跑大规模的模拟程序，算法的核心就是
: 矩阵的LU变换。这个东西得C语言的算法已经很成熟了，但是在DSP上如果不做优化的话
: ，基本上不能用，速度太慢了。但是如果用comipler的优化选项打开，选择优化到最少
: 的运行时间，编译好的程序跑出来的结果总是不对，一个4x4的矩阵的LU分解都算不对
: ，不知道为什么。
: 后来就是自己手工写asm码，loop unrolling加上DSP支持的SIMD，速度差不多提高了20
: 多倍。
|
e******e
发帖数: 147 | 18 最简单的方法：利用debug单步调试，观察cpu每个寄存器，在你程序运行时的变化情况
，看多了，你就有感觉了。
你玩过游戏，改过什么经验，物品，money等等，不是也是要研究binary code吗？一回
事。
对照着你使用的dsp/mcu的asm指令表去研究研究，对于你要关注的部分代码看明白就ok
，不一定要全部研究，也不一定要你自己去写。只是要建立高级语言如c/c++到目标代
码的一种影射。也就是说写出的c语言，脑子里就能反映出cpu寄存器怎么run的，
binary code是怎么分配，整个程序从头到尾怎么跑得。当然这个需要时间和经验的积
累。 |
r******s
发帖数: 925 | 19 改游戏是很久以前了，玩仙剑的时候，你写的真好，非常感谢
我现在用的是real-time PC + DSP，写的程序目前感觉还没出现什么大问题
可能是现在实现的功能和算法简单的缘故吧，什么时候也用你的方法试一试
ok
【在 e******e 的大作中提到】
: 最简单的方法：利用debug单步调试，观察cpu每个寄存器，在你程序运行时的变化情况
: ，看多了，你就有感觉了。
: 你玩过游戏，改过什么经验，物品，money等等，不是也是要研究binary code吗？一回
: 事。
: 对照着你使用的dsp/mcu的asm指令表去研究研究，对于你要关注的部分代码看明白就ok
: ，不一定要全部研究，也不一定要你自己去写。只是要建立高级语言如c/c++到目标代
: 码的一种影射。也就是说写出的c语言，脑子里就能反映出cpu寄存器怎么run的，
: binary code是怎么分配，整个程序从头到尾怎么跑得。当然这个需要时间和经验的积
: 累。
|
r******s
发帖数: 925 | 20 不错!
【在 k****f 的大作中提到】
: 嵌入式的cpu一般比较简单的，手写汇编还是可以的。
: 我曾经在intel cpu上手写过汇编，调用mmx，sse指令加速一个算法，
: mmd，比直接用c编译出来差不少的
:
: 20
|
|
|
p****s
发帖数: 32405 | 21 听着真是很强。。。。
我不会用汇编, 所以现在写个SDIO的driver, 要提高效率经常用的笨办法，就是
拿示波器去看底下的包是怎么收发的。
【在 e******e 的大作中提到】
: 最简单的方法：利用debug单步调试，观察cpu每个寄存器，在你程序运行时的变化情况
: ，看多了，你就有感觉了。
: 你玩过游戏，改过什么经验，物品，money等等，不是也是要研究binary code吗？一回
: 事。
: 对照着你使用的dsp/mcu的asm指令表去研究研究，对于你要关注的部分代码看明白就ok
: ，不一定要全部研究，也不一定要你自己去写。只是要建立高级语言如c/c++到目标代
: 码的一种影射。也就是说写出的c语言，脑子里就能反映出cpu寄存器怎么run的，
: binary code是怎么分配，整个程序从头到尾怎么跑得。当然这个需要时间和经验的积
: 累。
|
d*****l
发帖数: 8441 | 22 有时是不是也要考虑流水线和循环操作中前后数据的相关性啊.
人工去考虑和安排操作和指令来配合pipeline应当比compiler自己去优化更好吧。 |
b******a
发帖数: 215 | 23 this needs more time, experience and knowledge of CPU hardware.
As I know, a optimised ASM FIR algorithm can eliminate almost all the stalls.
This is many many times faster than written in C.
【在 d*****l 的大作中提到】
: 有时是不是也要考虑流水线和循环操作中前后数据的相关性啊.
: 人工去考虑和安排操作和指令来配合pipeline应当比compiler自己去优化更好吧。
|
e******e
发帖数: 147 | 24 ASM的本质就是数字信号0，1，单个语句或者很小功能实现ASM确实比C好那么一点点，
但是考虑的系统的设计复杂度，可读性，可靠性，可维护性等等，C和ASM 的混合编程
就显得非常有优势。
某些C代码经过complier翻译后，效率会低很多，可以使用嵌入asm代码的方式来进行改
善。
经过优化的C+ASM混合编程方式，完全可以到达任何优化的ASM的效率。对于稍大一些的
系统，比如代码超过1w行，你很难去将这样规模的ASM代码优化的很好。据说的东西，
都不靠铺，得自己做了才知道深浅。
通常的做法使用C语言来做整体框架设计，在某些部分用嵌入ASM的方法处理。
这样程序总体上可以可以享受到高级语言的设计方便的好处，同时又可以保持高效率。 |
G*******n
发帖数: 2041 | 25 memcpy会不会快一点
【在 r******s 的大作中提到】
: 不错!
|
x****u
发帖数: 44466 | 26 在程序里面到处优化是大忌，找出哪里真正该优化，比怎么优化程序重要100倍。
【在 r******s 的大作中提到】
: 不错!
|
