原创 UAL的指令描述格式的参考

UAL的指令描述格式的参考

嵌入式系统( Embedded system) 开发的核心, 往往围绕着 uController 的开发而进行.

也即是说, 在 hardware 的 designe 上, 我们致力于形成一个最小的可实现 uController 的系统, 并以此为核心, 构建从属的数据采样/控制的 hardware 子系统. 它可以是开环的, 更可能是闭环的.

在 PCB 的实现上, 随着近年来 uController 的不断进步, 尽管有着内部倍频的存在, 但是系统核心频率与总线(bus)频率仍然在不断提高, 它们共同影响了 uController 稳定运行. 在 PCB 的layout 上, 为了保证 uController 的正常工作状态, 以及外部高速bus 的信号的传输, 工程师们设计时往往小心翼翼对尺寸, 布局, 分层, 线宽, 射频等多方因素进行权衡.

同样, 软件体系构建在 uController 内部. 其设计调试编程的一般过程, 需要汇编器, 编译器, 链接器, 模拟器, 调试器的诸多配合. 今天的设计不断在复杂性上进行提升, 也就是工程师开始不仅仅要熟悉以往的前后台编程模式, 更可能自行设计一个简单的任务调度器(而不是操作系统, 因为任务没有通过stack 的方式独立), 而较复杂的应用, 即使在类似 cortex 的 microController variant 也就是 M variant 上, 都引入了(嵌入式)实时操作系统的应用. 今天的设计, 也仍然延续着以往嵌入式软件设计的一些固有特性, 特别是着重对软件的健壮性进行各种保护, 无论从多个冗余的条件语句还是到所谓的软件陷阱技术, 莫不体现了这一点.

如果我们回归到刚刚进入 embedded world 世界, 点亮第一个 led 的story 的源头, 从那个时候, 到多个项目结束的今天, 我们大致能够推出一些既成经验: 在嵌入式系统的开发过程中, 硬件设计在不断的总结过程中, 电路经验不断积累, 阶段性(而不是跃进性)的突破在层级进步. 故而硬件设计往往最终以积累与继承为主. 而软件设计, 从最初的功能实现型的开发, 到多个复杂难解的 bug 出现折磨, 软件开发的趋势, 往往向时序的理解, 以及任务的分派, 和对软件健壮性的强调为主.

所以, 我们觉得, 嵌入式设计, 最终是以 uController 为设计核心, 硬件上为 uController 提供最少干扰的环境, 软件上提供任务时序清晰, 健壮性较高, 容易移植的软件模块. 这样, 在新的嵌入式项目开发时, 工作经验就容易继承, 开发项目的成功率也提高.

如果说嵌入式设计围绕以 uController 为核心, 那么 uController 的设计/应用/学习的核心又在何处, 不同的工程师会从不同角度, 根据自己的项目体会与经验来理解.

如果从应用的角度出发, 我们抛开微控制器内部的运算器控制器, memory, io 硬件部分(它们往往基于某个总线协议, 如 AHB/APB 或者 AXI/APB 而连接在一起). 如果我们同时也不理会沙子中提纯si, 以及各种材质渗入与蚀刻以构建晶体管, 也不论最后的芯片封装.

那么我个人就觉得, 架构就是一颗 uController 的核心.

谈到架构, 这个汉语词汇似乎能让我们发散思维, 将诸多领域的概念纳入其中. 但实际上, 架构对应的专业词汇 Architecuture 在比如说 ARM 的文档中, 以及被赋予了专门的定义. 首先, 架构的核心就是指令集. 这并不让人感到意外.

好吧, 假设上帝赋予我们凭空创建 uController 的权利.

那么我最想做的, 就是, 啊` 请创建一颗 32-bit 或者 16-bit 的 uController 给我! 在 encoding diagram 方案上, 我要求 ADC 在 16-bit 上, 编码表要是: 0100000101RmRn, 其中 Rm 与 Rn 都是 3-bit 用来方便 encoding-specific psuedocode 的表达.

没错, 我说的其实就是 ARM 的 encoding diagram. 当我们完全按照 ARM 的编码表完成  instrution set 后, 想想看这是多么令人激动的事情! 这意味着 KEIL 和 IAR 几乎不加修改能够被我们使用, 数以万计的代码资源不浪费能够被我们项目移植...

但是, 如果上帝不帮我的话, 那么最终我必将因为触犯 ARM 的知识产权而被严惩.

这个荒诞的剧目可能深刻揭示, 作为架构的核心的指令集, 就是收到知识产权严密保护的基本企业知识产权的财富. 我们可以想当然创造一个新的RISC指令集, 引入合理不合理的新的编码表, 但是就是不能与 ARM 现有的指令集一致, 哪怕我们对今天已经如此成熟的 ARM 生态链垂涎三尺也不成.

当然, 架构不仅仅不包括指令集, 作为 programmer's model. 架构还包括了: 基本数据类型的定义(哪怕是我们假设中的微控制器仅仅只有 4-byte 的 word 类型, 我们至少也要定义它). register(包括有 core register, 以及 system register, 它们往往被 mapped memory).异常(包括了Interrupt)行为.  还有就是 memory 的 type , 属性, 以及 memory address 的空间分配.

回到文章标题(UAL的指令描述格式)的议题上来:

如我们在上文中提到的, 嵌入式设计以微控制器为核心, 微控制器以架构为核心, 架构以指令集为核心, 让我们观察一下指令集的例子, 无论是学习或者应用的目的.

最好的例子是 ADC. 原因就是, 以字母为序的指令集详解中, ADC 往往占据榜首.

研习 ADC instruction 的例子, 让我们容易进行各个指令集的历史继承关系的比较. 而且, 也对初学者有相当帮助, 可以作为学习笔记来进行理解.

让我们一起来观察 ADC 的例子(来自于 ARMv6-M ARM 文档, 后面一个 ARM 是 Architecture Reference Manual 的缩写):