对于内存受限的嵌入式芯片（包括MCU和成本要求的AP类芯片）来说，代码密度非常重要。同样功能的程序，如果代码密度过大，就可能导致因ROM空间装载不下而无法使用。所在，在嵌入式领域中，代码密度是最重要的指标之一。那么，代码密度由什么决定？如何提高代码密度呢？RISC-V的代码密度现状又如何？

PS:作者这里应该是笔误，代码密度越大，空间效率越高，所以不太可能由于代码密度过大导致ROM空间装载不下.:).

代码密度的决定因素

如上面的倒金字塔所示，代码密度主要由指令集、ABI、编译器、Runtime库、程序代码五个部分决定。处在金字塔的越底端，说明该因素的越底层，更新的频率越小，但辐射和影响的范围却越广

指令集

指令集是代码密度最根本的决定性因素，它决定了一个操作在最优的情况下需要编译成多少位宽的编码。

很多体系结构比如ARM、RISC-V、C-SKY都是16位指令、32位指令混编的，同样的一条指令，如果能够被编译成16位指令，那么它显然比编译成32位指令占用更小的空间；再比如，一个乘累加的操作，如果指令集中存在乘累加指令，那么它只需要一条指令来实现乘累加操作，如果没有则需要至少两条指令来完成相同的操作，假设指令都是32位的，显然一条指令将占用更少的空间。

由于指令集的编码空间是有限的，所以指令集设计的核心是将哪些指令（包括指令操作数的范围）放到编码空间当中，就像一个商场的店面是有限的，当我们把需求最广的商家引进来时，商场的销量就会达到最高。

ABI

ABI的全称是Application Binary Interface，是二进制级别的协议，它指导着编译器如何生成代码和二进制程序，同样也指导着用户如何写汇编代码。它主要包含函数调用约定（calling convention）、数据的对齐方式等内容。

其中对代码密度影响最大的就是函数调用约定，它规定了堆栈寄存器、链接寄存器、哪些寄存器寄存器需要在函数头尾保存和恢复、哪些寄存器可以作为参数寄存器等，还有一些特殊用途的寄存器。大部分特殊寄存器都是会被高频使用的，配合指令集设计可以降低代码密度；需要保存和恢复的寄存器个数同样也会影响代码密度。

编译器

编译器是开发者最直接接触的工具，也是给开发者体感最强的代码密度影响因素。它对代码密度的影响主要体现在两方面：

编译器本身的优化能力，优化能力的强弱是影响编译器产品竞争力的最主要的因素。
编译器的使用方法，比如GCC，除了添加-Os之外，还可以添加-ffunction-sections -fdata-sections -Wl,--gc-sections来删除没有用到的函数。

Runtime库

Runtime库是指程序运行所需的一些基本的函数库，它们一般都是预先编译好，和编译器一起打包发布，是工具链的一部分。由于这些函数的使用频率较高，一般程序都会用到一部分Runtime库的函数，对这些函数做针对性地优化会有比较好的收益。

程序代码

开发者书写的代码质量也会影响程序的代码密度，虽然编译器能够优化一部分冗余代码，但是并不能保证百分之百的优化，所以开发者也要注意代码的质量。

RISC-V架构的代码密度现状

RISC-V的代码密度表现一直被人诟病，那么，它的现状真的这么不值一提吗？

首先，RISC-V对代码密度做过一些专门的优化。在指令集方面，它通过量化分析的方法测试了spec等benchmark，找到高频指令并将它们放到16位指令的编码当中，这就是目前的compress指令集；在ABI方面，rv32e通过限制16个寄存器，使代码可以生产更多的16位指令；在编译器和Runtime中，它支持-msave-restore功能通过库函数调用的方式弥补了由于没有push/pop指令造成的一部分代码密度损失。这里需要特别指出的是，RISC-V的链接器做了较多的relax优化，即某些指令的目标符号距离比较接近的时候，可以优化使用更少的指令。比如函数跳转，比如具体在4k之内，可以使用一条jalr指令实现，而如果超过4k的话，则需要auipc+jalr或者lui+jalr两条指令实现。一般在未链接的object文件中，预留的都是指令条数最多的形式，链接之后很大一部分将被优化。如果测试的benchmark如果统计的是object文件，比如CSiBE，那么结果会比实际的要差一些。

那么，在做了这些优化之后，为什么RISC-V的代码密度还是被这么多人诟病呢？主要是由于compress指令集设计时，基于的benchmark是spec2006，它在应用PC端非常具有代表性，但在嵌入式领域却不具有典型性。所以在RISC-V 64位核中，它的代码密度表现还不错，但是在真正关心代码密度的嵌入式领域表现却不尽如人意。其次，ABI也需要重新针对嵌入式领域做量化评估和设计。

平头哥对RISC-V的代码密度优化

针对代码密度，RISC-V社区目前也在不断地优化中，比如code-size TG和EABI TG的成立。平头哥也参与其中，在优化代码密度的道路上不断前行。目前，平头哥所做的优化有如下两个方面：

Runtime库

平头哥设计开发了一套针对嵌入式领域的、最大化优化代码密度的Lower-Level Runtime Library。目前玄铁E902、玄铁E906和玄铁E907均已支持该Runtime库，它相对于libgcc提升40%；相对于Arm的macrolib，玄铁E902与M0-plus相当，玄铁E906、玄铁E907与M4相当。

ABI

目前，社区正在设计、制定针对嵌入式领域的新的ABI——EABI（Embedded ABI），它不仅会调整Calling Convention以减少中断延迟，也会考虑代码密度，使用量化分析地方法设计出一套对嵌入式领域优化的ABI。平头哥作为EABI Task Group的Co-Chair，也参与其中推动EABI的前进。

一文看懂RISC-V代码密度相关推荐

一文看懂：零代码、0代码、无代码平台是什么？怎么选？
注:零代码.0代码.无代码平台,指的基本是同一个意思,即不用代码开发.就能实现应用搭建的平台以前想要P一张好看的图片或者做一个很燃的视频,只能交给设计师&摄影师用专业的软件,但现在有了美图秀 ...
一文看懂：零代码平台是什么？怎么选？
在互联网高速发展的今天,工具产品呈现"傻瓜化"趋势,不是设计师也能用美图秀秀把自己相片处理得美美的:不是摄影师也能用抖音.手机剪辑软件制作出很燃的视频.当然,不会编程也能在零代码平 ...
一文看懂Stacking！(含Python代码)
一文看懂Stacking!(含Python代码) https://mp.weixin.qq.com/s/faQNTGgBZdZyyZscdhjwUQ 转载于:https://www.cnblogs.c ...
一文看懂 “极大似然估计” 与 “最大后验估计” —— 极大似然估计篇
参考: 唐宇迪<人工智能数学基础>第8章 Richard O. Duda <模式分类>第三章白板机器学习 P2 - 频率派 vs 贝叶斯派频率学派还是贝叶斯学派?聊一聊机器 ...
【机器学习】一文看懂贝叶斯优化/Bayesian Optimization
点击上方,选择星标,每天给你送干货! 来自:AI部落联盟今天想谈的问题是:什么是贝叶斯优化/Bayesian Optimization,基本用法是什么? 本文的定位是:帮助未接触.仅听说过.初次接触 ...
python读取excelsheet-一文看懂用Python读取Excel数据
原标题:一文看懂用Python读取Excel数据导读:现有的Excel分为两种格式:xls(Excel 97-2003)和xlsx(Excel 2007及以上). Python处理Excel文件主要 ...
【Python基础】一文看懂 Pandas 中的透视表
作者:来源于读者投稿出品:Python数据之道一文看懂 Pandas 中的透视表透视表在一种功能很强大的图表,用户可以从中读取到很多的信息.利用excel可以生成简单的透视表.本文中讲解的是如何 ...
怎么看电脑系统是win几_一文看懂arm架构和x86架构有什么区别
一文看懂arm架构和x86架构有什么区别本文主要介绍的是arm架构和x86架构的区别,首先介绍了ARM架构图,其次介绍了x86架构图,最后从性能.扩展能力.操作系统的兼容性.软件开发的方便性及可使用 ...
一文看懂async和“await”关键词是如何简化了C#中多线程的开发过程
一文看懂"async"和"await"关键词是如何简化了C#中多线程的开发过程当我们使用需要长时间运行的方法(即,用于读取大文件或从网络下载大量资源)时,在同 ...
判别两棵树是否相等设计算法_一文看懂生成对抗网络 - GANs？（附：10种典型算法+13种应用）...
生成对抗网络 – GANs 是最近2年很热门的一种无监督算法,他能生成出非常逼真的照片,图像甚至视频.我们手机里的照片处理软件中就会使用到它. 本文将详细介绍生成对抗网络 – GANs 的设计初衷.基 ...

一文看懂RISC-V代码密度

代码密度的决定因素

指令集

ABI

编译器

Runtime库

程序代码

RISC-V架构的代码密度现状

平头哥对RISC-V的代码密度优化

Runtime库

ABI

一文看懂RISC-V代码密度相关推荐

最新文章

热门文章