补码乘法是我在数字电路和底层开发里反复打交道的东西，面试时问、写RTL时用、调C语言崩溃还要回来翻。很多人会做乘法，但碰到符号位就含糊了：为什么两个负数相乘结果是对的？为什么有符号乘法和无符号乘法指令不一样？为什么Matlab里一读十六进制就变成巨大的正数？这篇就把有符号数乘法从补码表示、手算逻辑、硬件实现到软件实战一次讲透，顺手把Matlab十六进制转有符号数的常见坑也填掉。
1. 有符号数的表示：补码才是乘法的地基
1.1 原码、反码与补码的本质差别
计算机里的有符号数，常见表示方案有原码、反码、补码三种。原码最直观：最高位是符号位，0表示正，1表示负，其余位是绝对值。比如4位原码下，3是0011，-3是1011。但这种方案有个很尴尬的问题——0的表示不唯一，会出现0000表示+0、1000表示-0两个零，做运算时还得单独处理符号位和数值位，电路设计变得很啰嗦。
反码在原码基础上把负数的数值位全部取反，比如-3对应1100。0仍然不唯一。补码则彻底解决了这个问题：正数的补码就是原码本身，负数的补码是"反码加1"，-3在4位补码下是1101。补码方案下0只有一种编码0000，而1000则用来表示-8，这就让4位有符号数的取值范围变成了-8到7，比原码反码多了一位。
三种编码对同一个位模式可以表示完全不同的值，这个在乘法里是致命因素。比如4位二进制1101，按原码读是-3，按反码读是-2，按补码读也是-3，按无符号数读是13。如果硬件电路不知道操作数的类型，乘法结果就是乱的。这也是"有符号乘法"和"无符号乘法"必须区分开来的根本原因。
1.2 补码的模运算本质：为什么它可以"负负得正"
补码最漂亮的点在于，它不是人为发明的一种奇怪规则，而是模运算的必然结果。所谓模运算，你可以理解成一个只有有限刻度的钟表。4位二进制能表示的数字范围是0到15，就像钟面上只有16个刻度。在这个世界里，减去1和加上15是完全等价的操作，因为16就自动"溢出"归零了。
-3在4位补码里为什么是1101？因为13加3等于16，而16在4位世界里等于0，所以13就是-3的"替身"。这就是补码的本质：用（2^N - x）来表示负数，使得负数也能直接参与加法运算，不需要单独的减法器。
理解了这一点，乘法的道理就顺了。若x和y是两个有符号数，其补码位模式分别记为X和Y。把它们当作无符号整数相乘得到XY，再对2^N取模（即截断到N位），由于模运算的性质，XY ≡ x*y (mod 2^N)。也就是说，负数参与乘法时，符号位自然参加运算，截断后低N位的结果仍然正确，这正是"负负得正"的数学根源。
2. 手算补码乘法：符号扩展与截断的数学解释
2.1 从无符号乘法到有符号乘法
我们先回顾无符号二进制乘法。乘数和被乘数逐位相乘再移位累加，乘数第i位为1就把被乘数左移i位后累加。比如4位无符号数1101（13）乘以0011（3），结果是一串累加，最终得到39。这个过程本质上是，把乘数每一位的权重2^i都乘到被乘数上，然后累加。
问题来了：如果1101是有符号数-3呢？按无符号方式直接算，1101乘以0011等于39，显然不对。有符号乘法的正确做法是先做符号扩展，把两个操作数扩展到足够宽的位数，再执行无符号乘法，最后取需要的低位数。
符号扩展是说，正数在高位补0，负数在高位补1。为什么补1？回到补码的模运算，4位-3（1101）扩展到8位，应该保持值不变。因为-3 = 13 mod 16 = 13 mod 256，而13用8位无符号表示是00001101，这才是-3在8位补码里的位模式11111101对应的"替身"。所以符号扩展补1，本质上是保持模2^N不变的同时换到更大的模2^M。
2.2 两个数值实例算透补码乘法
我拿-3乘以5来演示。4位补码下，-3是1101，5是0101。先分别符号扩展到8位：-3变成11111101，5变成00000101。然后按无符号乘法：
11111101 x 00000101 --------------- 11111101 +1111110100 --------------- 111111000001结果为111111000001，取低8位11110001，这是-15的8位补码，正确。
再看-3乘以-5。补码分别1101和1011，符号扩展到8位为11111101和11111011。按无符号乘法累加：
11111101 x 11111011 ---------------- 11111101 111111010 1111110100 11111101000 111111010000 ---------------- 11110100000111取低8位为00000111，等于7，-3乘以-5等于15，结果也正确。注意到上面累加时中间多个部分积，但高位部分不影响低8位结果，直接丢弃。
从这两个例子能直观看到，符号扩展保证乘法运算中每个部分积的"真实价值"是正确的，截断到目标位宽后，剩下的低N位恰好就是补码乘法结果的位模式。
2.3 符号扩展的"为什么"
很多人会问：符号位明明是1（表示负数），为什么补1不会把乘积放大？关键在于，在补码的数学体系里，11111101并不是"-3的绝对值加符号"，而是-3在这个二进制位数下的唯一表达。符号扩展后的位模式在更大的模空间里仍表示同一个负数，所以参与无符号乘法时，叠加出来的结果也在更大空间里保持着正确的模值。这就像在钟表上，11点也可以写成23点、35点，它们在同一模数下是同一个时刻。
实际硬件乘法器，标准的做法就是先把操作数符号扩展到乘积位宽，再交给无符号乘法阵列。这样设计简单，而且完全绕开了单独处理符号位的麻烦。
3. 硬件乘法器的工程实现：从移位相加到Booth到Wallace
3.1 最基础的移位相加乘法器
在数字电路里，最直觉的乘法器就是移位相加：每个时钟周期检查乘数的一位，是1就把被乘数加到部分积里，然后被乘数左移一位，乘数右移一位。N位乘法需要N个周期完成，虽然慢，但面积小，在一些低速低功耗场景里仍然适用。
有符号场景下，移位相加乘法器有两个选择：一是先把操作数做符号扩展，然后按无符号方式跑；二是在最后一次移位中把有符号右移符号位处理好。工程上绝大多数人选择前者，因为无符号乘法器已经被验证得很成熟，符号扩展只是在前端加几步逻辑。
3.2 Booth重编码：减少部分积的关键
移位相加的思路简单，但N个周期对高性能场景太慢。Booth算法则是通过"重编码"把部分积数量几乎减半，核心思想是：连续的1序列可以转换成一个减法和一个加法，比如01110（14）可以看成10000减去00010，也就是16减2，而16和2都只需要一次位移。
Booth重编码的规则是两位一组看：乘数位对(0,0)原地不动，(0,1)加被乘数，(1,0)减被乘数，(1,1)原地不动。改进的Radix-2 Booth把乘数分成两位一组，每步只看一个"窗口"，让部分积数量减半，代价是每次累加可能要做减法（即取补码后加1）。比如计算3乘以-2，按Booth重编码，-2的位模式1010重新编码后得到-1和-2两个非零项，部分积数量比逐位检查更少。Booth算法在硬件里是主流方案之一，现代处理器中的乘法器很多就是做的优化版。
3.3 Wallace树与FPGA中的DSP实现
Booth减少部分积数量，Wallace树则是把部分积的累加过程并行化。传统移位相加是一列一列串行累加，Wallace树则利用全加器和半加器，把三行部分积压缩成两行（进位保留加法），反复压缩，最后只剩两行再走一个快速加法器。这种"进位保留"结构把加法延迟从O(N)降到了O(log N)，乘法速度大幅提升。代价是布线复杂、面积大，所以一般在大规模高性能设计里使用。
FPGA上还有更省事的路径：大多数FPGA内置了DSP Slice，里面有专用的乘法器硬核。在Vivado或Quartus里例化乘法器IP时，只需要正确设置"有符号/无符号"选项，低位宽乘法根本不用自己拼。这里有个很常见的坑：Verilog里单纯写a * b，如果a和b是reg类型默认是无符号数，做有符号乘法必须先声明为signed或使用$signed()，否则乘积符号会完全错乱。我见过不止一个同事因为漏了这个，仿真波形一路浩大的错误数字，折腾半天才发现只是类型问题。
4. 软件有符号乘法：溢出、符号扩展与编译器优化
4.1 溢出是未定义行为：编译器怎么"钻空子"
C/C++的有符号整数溢出是未定义行为（UB），这不是文案，而是真正影响程序行为的"杀手锏"标志。编译器看到一个表达式a * b时，它可以根据"a、b正常范围内不该溢出"这个前提做优化，把一些看似等价的代码改写成完全不同的逻辑。
我举一个实际踩过的例子。有一段代码：
int check(int a, int b) { if (a > 0 && b > 0) { return a * b > 0; } return 0; }如果你是程序员，直觉是：a、b都是正数，乘积当然应该大于0。但在GCC开启-O2时，这段代码会被直接优化成return 1。原因是编译器认为有符号乘法溢出是未定义行为，既然不该溢出，a*b就必然是正值，那么a*b > 0恒真，于是整个分支直接变成常量1。如果a和b实际是一个溢出的大值，程序在用户眼里就"莫名其妙地返回了错误结果"。
另一个经典例子是把乘法结果赋值给更宽类型：
int64_t f(int a, int b) { return (int64_t)(a * b); }这里的乘法仍然是32位的，溢出行为未定义。正确写法是先转类型再乘：(int64_t)a * b。这个坑在代码评审里反复出现，很多人以为赋值给int64_t就安全了，其实乘法在赋值前已经完成。
4.2 安全的溢出检测与饱和乘法
既然溢出是UB，那真正要防溢出时就需要可靠手段。GCC和Clang都提供了内置函数：
#include <stdio.h> #include <limits.h> int main(void) { int a = 100000; int b = 100000; int result; if (__builtin_mul_overflow(a, b, &result)) { printf("乘法溢出，%d * %d 超出 int 范围\n", a, b); } else { printf("乘积 = %d\n", result); } return 0; }__builtin_mul_overflow会根据目标类型自动判断溢出，并给出正确结果，这是目前最推荐的溢出检测方案，也支持long、long long等类型。在需要"饱和"语义（超过上限就钳到上限，低于下限就钳到下限）时，先用这个函数检测，再手动钳位，是稳妥的做法。
4.3 混合宽度乘法与隐式类型转换
软件里更隐蔽的问题是混合宽度乘法。C语言的整型提升规则会自动把较小的类型转换成int参与运算，这通常没问题。但int和long long相乘时，int会被转成long long。问题会出现在：int与unsigned int混合时，int会被转成unsigned int，符号位没了，负数变成了巨大的正数，乘积结果完全失控。
int a = -2; unsigned int b = 10; long long r = a * b; // a先被转成unsigned int，即4294967294，r变成42949672940这种问题在处理协议字段、解析文件数据时尤其容易触发。假设你从二进制流里读了一个16位有符号数（int16_t），又跟一个uint32_t的字段相乘，如果不小心做了隐式转换，负数立刻"爆炸"。解决办法非常机械但有效：在乘之前用显式转换，统一符号类型和位宽，比如(int64_t)a * (int32_t)b，别靠编译器猜。
5. 实战视角：Matlab的十六进制转有符号数再乘
5.1 常规思路的坑：hex2dec与uint16/uint32
今年网络上关于"Matlab 十六进制转有符号数"的搜索热度明显上升，我猜大部分是数据解析和仿真场景。最直接的坑：Matlab的hex2dec函数返回的是double类型的无符号十进制值，比如hex2dec('FFE0')返回65504，这看起来像是-32的无符号表达。如果直接拿它跟有符号数相乘，数学意义完全错了。
更要命的是hex2dec对长十六进制字符串会丢精度，因为double的有效精度只有53位，超过就不精确了。至少32位十六进制（8个字符）以内没问题，但64位就非常危险。所以在转换有符号数时，千万不要直接用hex2dec然后做加减法，而是用uint16、uint32、typecast这些专门处理位模式的工具。
5.2 16位与32位十六进制有符号转换示例
16位转换的正确做法有两种，第一种是数值型判断法：
hex_str = 'FFE0'; dec_unsigned = hex2dec(hex_str); % 得到一个0~65535的数 if dec_unsigned >= 2^15 signed_val = dec_unsigned - 2^16; else signed_val = dec_unsigned; end第二种是直接用typecast，更贴近底层位操作：
hex_str = 'FFE0'; val_signed = typecast(uint16(hex2dec(hex_str)), 'int16');第一条先把字符串变成uint16，第二位级类型重解释成int16。对于32位：
hex_str = 'FFFFFF9C'; val_signed = typecast(uint32(hex2dec(hex_str)), 'int32');在写仿真时我习惯把这段封装成一个工具函数：
function val = hex2signed(hex_str) n = numel(hex_str) * 4; uval = uint64(hex2dec(hex_str)); if bitget(uval, n) val = typecast(uval, 'int64') - 2^n; else val = typecast(uval, 'int64'); end end这个函数按输入字符串长度自动判断位数，逻辑上等价于先转uint再加判断。注意44位以上的十六进制字符串转换前要分块，否则hex2dec的double还是扛不住。
5.3 数据解析中如何避免精度损耗
在做仿真数据回放或者从DSP/FPGA抓回的数据文件里解析十六进制时，我习惯把所有字段一次性地转成对应类型，再参与运算。这里有三个经验供参考：
第一，能在读文件时就指定类型最好。Matlab的fread支持直接按int16、int32读取二进制文件，根本不用先读十六进制字符串再转换。只有数据文件本身是文本形式（比如日志导出的hex），才需要hex2dec转。
第二，位数超过32位时建议分两步：全是0x开头的大数，先拆成高16位和低16位分别转uint16，再拼成整型（用bitshift和bitor），或者直接用MATLAB的uint64配合位操作，不要依赖hex2dec的double中转。
第三，转换成有符号数后再做乘法，务必把结果类型统一。比如你解析到两个int16的数，相乘前先转换成int32：
a_int16 = int16(hex2signed('FFE0')); b_int16 = int16(hex2signed('0010')); result = int32(a_int16) * int32(b_int16);这样才能保证乘积可以安全超出int16范围而不截断。直接写a_int16 * b_int16时，Matlab默认按精度更高的类型输出，结果又会带符号格式的坑，最好显式指定。
结合我自己在芯片验证和嵌入式调参两个场景的使用体会，十六进制转有符号数最稳妥的心法是：先确认位宽，再做位数判断，最后用typecast或位运算一次性转换，中间不要经过double的算术运算。顺便提一句，Verilog仿真里如果从文件里读到的是十六进制文本，也建议先判断符号位再扩展，别直接乘，这个和Matlab的坑一模一样。
有符号数乘法看着基础，真正吃透它需要把补码数学、硬件算法和软件语义串起来。我这里分享的都是实际工程中踩过的坑和反复测试过的方法，希望对你有用。如果你在FPGA或者C语言里也遇到过什么诡异的乘法问题，建议先回来看看符号位和类型，八成问题就出在这里。
