Los opcodes ud0 y ud1 en la arquitectura x86 no son instrucciones indefinidas en el sentido arquitectónico, sino secuencias de bytes que nunca recibieron una definición formal. Su existencia se debe a que el decodificador de instrucciones de Intel los permitía pasar sin asignarles un significado específico, aprovechando un patrón de parámetros común en el rango de instrucciones de procesamiento de vectores (SSE). Esta situación creó un 'purgatorio' donde las instrucciones eran técnicamente inválidas, pero el hardware las procesaba de forma consistente, lo que llevó a su adopción como opcodes no oficiales.
El mecanismo de decodificación permitía al procesador asumir que todas las instrucciones en ese rango utilizaban dos parámetros: un registro de memoria (mm) y un segundo parámetro (mm/m64). El decodificador usaba los bits restantes para determinar la operación aritmética (suma o resta) y el tamaño de los datos. Cuando se presentaba un código como 0F FF, el decodificador solo detectaba la inconsistencia en el último paso, generando una excepción de instrucción inválida. Sin embargo, la introducción de nuevas instrucciones SSE, como PADDQ, requería un espacio en el rango 0F FF, lo que obligó a Intel a mover PADDQ a una ubicación menos natural (0F D4) para mantener la compatibilidad con el comportamiento previo de 0F FF.
Este fenómeno no es exclusivo de x86. En AArch64, existen 65.536 instrucciones permanentemente indefinidas, y en PDP-10, el opcode 000 era ilegal pero aceptaba parámetros de registro y memoria. Además, el nombre 'ud1' fue introducido por el ensamblador NASM, que lo usó para referirse a esta instrucción legada, mientras que Intel la documentó internamente como 'Undefined Opcode'. Este caso ilustra cómo la falta de documentación formal y la presión por mantener la compatibilidad hacia atrás pueden crear instrucciones que, aunque no están en la arquitectura oficial, se comportan de manera predecible y útil para los desarrolladores.