嵌入式编程

Question

我发现这个问答网络:

问:优化的char,short或int类型哪个更好？

答:在可能的情况下,最好避免使用char和short作为局部变量.对于char和short类型,编译器需要在每次赋值后将局部变量的大小减小到8位或16位.对于有符号变量,这称为符号扩展,对于无符号变量,称为zeroextending.它是通过将寄存器左移24或16位,然后将有符号或无符号右移相同的量来实现的,取两条指令(无符号字符的零扩展需要一条指令).通过对局部变量使用int和unsigned int可以避免这些转换.这对于首先将数据加载到局部变量然后处理局部变量内的数据的计算尤为重要.即使数据输入和输出为8位或16位数量,也值得考虑将它们作为32位数量处理.

它是否正确？我认为最好避免因为算术转换而导致char和short(很可能它们会被转换为int或long,这将导致编译器生成额外的指令).

问:如何减少基于ARM的系统中的函数调用开销？

答:避免使用部分传递给寄存器且部分传递给堆栈的参数的函数(split-argument).当前编译器无法有效处理:所有寄存器参数都被压入堆栈.

·避免使用可变数量的参数的函数.Varargs功能....

关于'varargs' - 这是因为参数将通过堆栈传递吗？什么是args部分传递到寄存器中的函数,部分通过堆栈,你能举例吗？

我们可以说,函数参数的传递方式(通过寄存器或堆栈)在很大程度上取决于架构吗？

谢谢 !

Answer 1

简单地说:关于优化的建议是误导性的.不一定错,但不完整.

您的源代码似乎是CodeProject.他表示他主要谈论ARM的优化.

首先,它是高度依赖于处理器的,如何处理char和short.根据体系结构的不同,转换可能为零或成本最低,具体取决于它们何时以及如何发生 - 在加载时,操作类型,可以并行运行的指令可以是免费的,具体取决于其余部分.代码 - 例如TI DSP c64架构,每个周期可运行8个操作.通常,最有效的使用将是"本机"整数大小,但它也取决于数据的来源 - 加载,修改和存储返回字符/短数据可能比加载和转换为int更有效,修改,并以char/short存储回来.或者它可能不会 - 它取决于架构和正在执行的操作.编译器通常会更好地了解是否为您执行此操作.

其次,在很多情况下,很多架构char和short都和int一样快,特别是如果计算避免了对int的隐式转换.注意:这很容易在C中搞乱,比如"x = y + 1" - 强制转换为int(假设x和y是char或short),但好处是几乎所有编译器都足够智能优化 - 为您转换转换.使本地为char/short的许多其他情况将导致编译器根据以后使用的方式优化掉任何转换.这是因为在典型的处理器中,char/short的溢出/环绕与将其计算为int并在存储上转换(或者通过简单地将该寄存器作为char/short在稍后处理)的结果相同操作 - 获得'免费'的转换).

在他们的例子中:

int wordinc (int a)
{ 
   return a + 1;
}
short shortinc (short a)
{ 
    return a + 1;
}
char charinc (char a)
{ 
    return a + 1;
}

在许多架构/编译器中,这些将在实践中同样快速地运行.

第三,在某些架构炭/短路是比INT快.自然大小为8或16位的嵌入式架构(当然不是您现在想到的那种开发)就是一个例子.

第四,虽然在现代ram-heavy,大缓存处理器环境中通常不是一个大问题,但是保持本地堆栈存储大小不变(假设编译器没有将其提升到寄存器)可能有助于提高缓存访问的效率,尤其是级别-1个缓存.

另一方面,如果编译器不够智能,不能将它隐藏起来,本地char/shorts作为参数传递给其他函数(特别是不是文件本地的"静态"函数)可能需要向int转换.同样,如上所述,编译器可能足够聪明以隐藏转换.

我不跟你引用的站点开始同意这种说法:

虽然有许多指南可用于C代码优化,但是对于您正在编程的编译器和机器的全面了解是无可替代的.