在较早的时期，微代码在cpu中大量使用：每条指令都被拆分为微代码。这可以在适度的cpu中启用相对复杂的指令集（考虑到具有许多操作数模式和八个32位寄存器的Motorola 68000可以安装在40000个晶体管中，而单核现代x86将拥有超过1 亿个 ）。这不再是真的。出于性能原因，现在大多数指令都是“硬连线”的：它们的解释是由任何微代码外部的非柔性电路执行的。
在最近的x86中，可能有一些复杂的指令（例如fsin（在浮点值上计算正弦函数）用微码实现），而简单的指令（包括与imul进行整数乘法）却没有。这限制了使用自定义微代码可以实现的目标。
话虽这么说，微码格式不仅非常特定于特定的处理器型号（例如，奔腾III和奔腾IV的微码不能彼此自由交换- 而且，当然，将英特尔微码用于AMD处理器已不可行了）问题），但它也是受严格保护的秘密。英特尔已经发布了一种操作系统或主板BIOS可以更新微码的方法（必须在每次硬重置后完成；更新保存在易失性RAM中），但是微码内容 未记录在案。在英特尔®64和IA-32架构软件开发人员手册（第3a卷）描述了更新过程（第9.11节“微码更新工具”），但指出实际的微码已“加密”并且校验和已满时。措词含糊不清，几乎可以隐藏任何种类的密码保护，但最重要的是，对于除英特尔以外的其他人来说，当前不可能编写和尝试一些自定义微代码。
如果“加密”不包含数字（非对称）签名，并且/或者如果英特尔员工以某种方式破坏了保护系统，那么可以想到，一些非凡的逆向工程工作 可能 使人们能够产生这种微代码，但是鉴于适用性可能有限（由于大多数指令都是硬接线的），就编程能力而言，这样做的机会不大。
602392714
清零编程群