Una de las ideas que sostienen RISC-V es que no todo el mundo necesita la misma CPU. La arquitectura reserva espacio de codificación para instrucciones que quedan fuera del ISA estándar y de las extensiones ratificadas, precisamente para que los fabricantes puedan añadir las suyas. Jon Taylor publicó el 22 de junio de 2026 en el blog de Canonical un repaso de cómo encaja ese tipo de hardware con Ubuntu, y dónde están los límites.
Una instrucción personalizada es la que un diseñador de chip añade más allá de lo que define el estándar. Los motivos habituales son concretos: acelerar operaciones criptográficas en dispositivos embebidos, procesamiento de audio con DSP a medida (el ejemplo que cita es el SIMD DSP del ESP32-P4 de Espressif), tipos de datos propios para machine learning con mejor relación rendimiento/consumo, o controlar aceleradores externos de forma más directa que con periféricos mapeados en memoria.
La clave para saber qué hace falta en Ubuntu está en una distinción técnica: si la instrucción necesita o no guardar estado adicional en el procesador.
Sin estado: PPAs y nada más
Cuando una instrucción solo procesa datos y no añade registros ni estado que el sistema operativo tenga que preservar, no hay que tocar el SO. El flujo recomendado se apoya en la infraestructura de Launchpad. Distribuyes librerías precompiladas o un toolchain a medida a través de PPAs (Private Package Archives), compilas tu aplicación contra ese toolchain y listo. La ventaja de hacerlo así es que sigues recibiendo los parches de seguridad y mantenimiento de Canonical para el resto del sistema, además de la ganancia de rendimiento del hardware personalizado.
Con estado: kernel propio, y te lo mantienes tú
El caso complicado es el de las instrucciones que sí añaden estado al procesador. Aquí el sistema operativo tiene que poder guardar y restaurar ese estado en los cambios de contexto, así que necesitas un kernel a medida. Para eso Canonical ofrece un “image cookbook” con el que construirlo, además del toolchain y las aplicaciones de espacio de usuario en PPAs.
El aviso es directo y conviene leerlo antes de meterse: ese kernel personalizado no lo mantiene Canonical. Las actualizaciones de seguridad y los parches corren de tu cuenta. Los paquetes que vienen de los repositorios estándar sí siguen soportados, pero el kernel modificado queda fuera de esa garantía.
Detección en tiempo de ejecución con hwprobe
El otro punto práctico es la portabilidad. Si compilas binarios que asumen una extensión concreta y luego corren en hardware que no la tiene, te llevas un trap por instrucción ilegal. La recomendación de Canonical es usar hwprobe, que permite al código de usuario preguntar al kernel qué extensiones admite el hardware en el que se está ejecutando.
Con esa información puedes aplicar alternativas en lugar de fallar: por ejemplo, recurrir a una implementación de coma flotante por software cuando la unidad correspondiente no está presente. Es el patrón sensato para distribuir software que tiene que funcionar en una familia de chips RISC-V variada, no en un único modelo.
Para quien trabaje con silicio RISC-V a medida, el reparto queda claro: si tu instrucción no guarda estado, te quedas en espacio de usuario con PPAs y mantienes todas las garantías; si lo guarda, asumes el kernel y su mantenimiento. Y en ambos casos, detectar capacidades en runtime antes de usarlas evita sorpresas al cambiar de placa.
Fuente
Basado en How to use RISC-V custom instructions with Ubuntu, publicado por Jon Taylor en el blog de Canonical el 22 de junio de 2026.