在C/C 算法设计中使用任意位宽[2]

　　算法C数据类型

　　算法C数据类型是一种基于类的C 库，其实现了任意长度的整数及定点类型，而这些可自由访问的类型有一系列好处，包括统一及良好定义的语义，更有媲美C/C 内置数据类型的运行时速度，对比SystemC中相应的类型，其运行速度也超过10倍以上。这些数据类型能用于任何符合C 或SystemC规范标准的程式中，并拥有高度可合成的语义。

　　语义

　　语义的统一性和一致性是避免在算法中，发生功能性错误的关键，以下的例子，也说明了这点：

　　众所周知，变量ActLength的范围为1至255，万一编译器的合成不知道其范围，就不能进行相应的优化，他的声明就会从int变为更严格的sc_uint<8>类型;虽然合成会得到更好的结果，但设计就仿真得不正确了。在经过一番调试之后，找到了问题的源头：在比较表达式k >= ActLength中，两个操作数变成了一个signed int和一个unsigned long long(为64位无符号整数，其是sc_uint类型的基类型)之间的比较。对此的解释是：C/C 整数提升规则指定了在进行比较之前，会把操作数int提升为一个unsigned long long，例如，假如k的值为 -1，在提升为unsigned long long之后，他会变成2^64 – 1。

　　像这样语义中的问题一般会很难以察觉，且是和位宽相关的，例如，可能有人想扩大某个现有算法的位宽，只有看到结果时，才知道是行不通的;这个问题也可能是和特定平台相关的，例如，对1 << 32(两个操作数都是int类型，结果也是int类型)大家期望返回0，但在大多数平台(或编译器)上，他都会返回1(没有移位，只因为第二个操作数较低的五位被计算进来了);当第一个操作数是个64位整数时，平台依赖性会表现得更加明显及频繁。主要的问题是C/C 标准没有指定在32位整数情况下移位值(第二个操作数)超出0至31范围、或在64位整数情况下移位值超出0至63范围时的行为。不幸的是，像sc_int、sc_uint这样的数据类型也不能为用户避免这类平台依赖性的问题。

　　算法C数据类型被设计用于提供统一且一致的语义，因此，他们是可预测的，例如，对有符号数混用一个无符号操作数仍会产生期望的结果;这些类型的长度不受限制，所以就不存在所谓的精度问题。任何的操作——包括移位和除法——都有完整且一致性的定义，混合不同的类型也能得到期望的结果，如，当x为一个C内置类型，而y是个算法C类型时，表达式x y和y x均能返回相同的结果。

　　运行时间

　　我们的目的是为了在支持任意长度类型及避免用户碰到前述语义问题的前提下，得到使用内置类型(位宽不超过64位)手工C/C 编码优化过的运行时间。算法C类型是为快速执行及易于合成的语义而设计及实现的，任何操作的位宽由C 编译器静态确定，这就避免了动态内存分配，减少了运行时间，也使得语义更加易于合成。另外，实现也为速度进行了优化，因此可能会调用更多的专用及高效代码，充分利用了当今编译器的优化特性。

　　表1：规格化为ac_fixed的运行时间比较

　　表1是当定点算术用算法C定点类型ac_fixed来建模时，各种不同的运行时比较;float的实现在图2中，sc_fixed_fast为SystemC中精度受限的定点数据类型，sc_fixed为任意精度的定点类型。实际中对FIR滤波器进行10^8次调用，TRN/WRAP的运行时间为6.5秒，RND/SAT为29秒。其他类型的运行时间也能从这张表中依次推出，如sc_fixed TRN/WRAP将花费6.5s × 227 = 1476s(将近25分钟)。作为参考，图1中的算法(使用无定点建模的float)花费时间为3.5s(比起使用定点建模的ac_fixed，慢了近两倍)。

　　上述的运行时间数据，均由GCC 4.1.1测量得来，而在之前版本的GCC或Visual C 2005中得到的数据大致接近。

　　另外，运行时间也能通过整型数据类型或位操作进一步缩短。表2为一个DCT算法的相应结果，他由一个每次读写2位的移位操作得来，和此对比的运行时间为SystemC精度受限的sc_int和任意长度的sc_bigint。

　　表2：规格化为ac_int的运行时间比较

　　结论

　　基于通用标准ANSI C ，这种新的整数和定点算法C类型允许算法及系统设计者指定任意位宽，从而提供比传统数据类型高200倍的仿真效率。这些新数据类型可成为C-to-RTL设计链中很有价值的一环，及在整个实现流程中确保了任意位宽的精度。

[1] [2]