Opinión del editor: En términos generales, somos grandes fanáticos de RISC V. Hace algunas cosas muy bien, maneja muchas otras lo suficientemente bien y tiene signos claros de adopción y atractivo. Satisface una necesidad real del mercado de una manera innovadora, exactamente lo que nos gusta ver en nuestra tecnología. Así que decimos esto desde una posición de amor: RISC V va a tener un gran problema de software. La buena noticia es que puede que no importe.
Primero, algunos antecedentes. RISC V es una arquitectura de conjunto de instrucciones (ISA) de código abierto , una alternativa "gratuita" a Arm. Las ISA proporcionan un conjunto de "modelos" comunes, importantes pero poco atractivos para los procesadores. Cada procesador necesita lo que proporciona un ISA para hacer algunos cálculos básicos. Requieren mucho trabajo para diseñar y mantener, pero no proporcionan mucha diferenciación en el producto final, lo que significa que las empresas de chips que los utilizan ven una gran ventaja en subcontratar este trabajo a un tercero como Arm.
El objetivo de los procesadores es ejecutar algún tipo de software. Y aunque el ISA y el desarrollador de software están separados por varias capas, los ISA son tan fundamentales para los chips que los cambios en un ISA crean verdaderos problemas de software.
Intente descargar algún lenguaje de programación popular en una nueva MacBook con tecnología Apple M1 y es probable que descubra que el software no funciona en la M1 o requiere alguna versión beta alternativa. En realidad, esto es bastante importante porque significa que cualquier persona que ejecute código heredado tiene que soportar una fricción significativa para cambiar a una nueva ISA.
Los ISA son increíblemente pegajosos, cambiar a uno nuevo es algo que la mayoría de las empresas de chips detestan hacer. Por ejemplo, Qualcomm ha estado construyendo chips basados en Arm durante décadas, y aunque Arm los está demandando, es poco probable que Qualcomm mueva sus productos principales a RISC V porque haría que todo el software escrito para chips basados en Qualcomm fuera difícil de manejar. , si no inviable. No queremos exagerar esto, cambiar no es imposible, es simplemente difícil. Como dijimos anteriormente, es mucha fricción.
Esto podría haber sido un gran problema para la adopción de RISC V. Sin embargo, entró en el mercado en un momento casi perfecto. Justo cuando Arm entró en hibernación en los brazos mimados de Softbank y perdió su motivación para atraer nuevos clientes, las nuevas empresas de semis comenzaron a brotar nuevamente por primera vez en una década. Eso incluye el crecimiento incipiente de las nuevas empresas de semis de EE. UU. y una explosión absoluta de ellas en China. Ninguna de esas empresas tenía décadas de dependencias heredadas de Arm y estaban felices de optar por la solución que no costaba nada.
Pero hay un problema con todo esto. RISC V es de código abierto, lo que significa que cualquier persona que desee diseñar un chip RISC V tiene en gran medida la flexibilidad de realizar todo tipo de cambios en su implementación específica de ISA. Eso significa que el RISC V de todos es un poco diferente. La organización RISC V previó este problema y estableció un conjunto de requisitos de compatibilidad y, aunque todos quieren cumplirlos, no existe un mecanismo de aplicación real para evitar que suceda.
Esto significa que la implementación de los principales diseñadores de chips independientes RISC V como SiFive, Andes y CodaSIP puede ser ligeramente diferente. Todos cumplen completamente con todas las reglas, pero algunas personas las cumplen más completamente. Y dentro de las muchas grandes empresas de chips con diseños RISC V, quién sabe qué está pasando.
Esto probablemente significa que el software escrito para un chip RISC V no se ejecutará en otro chip RISC V, o al menos no funcionará bien.
Érase una vez que habría sido un tapón de espectáculo. La década de 1980 vio toda una guerra de sistemas operativos cuyo resultado dependía en gran medida de los chips e ISA subyacentes. Este tipo de problema de software habría obstaculizado gravemente el atractivo de RISC V, especialmente para algunos de los proyectos más ambiciosos, como CPU para servidores. Pero esta vez será diferente. En realidad, hay dos razones por las que esta fragmentación del software RISC V puede no ser tan importante.
Primero, la forma en que usamos el software ha cambiado. Los sistemas operativos importan menos que antes debido a Internet y la computación en la nube (todavía importan pero no de la misma manera). Mientras ese procesador subyacente pueda manejar el tráfico web básico, habrá una forma de ejecutar software en él. Es probable que haya problemas para migrar muchas aplicaciones de software comunes a RISC V y, como hemos señalado a menudo, este es el factor que mantuvo a Arm fuera del centro de datos, pero eso es solo una pequeña parte del mercado.
La segunda razón por la que esto puede no importar mucho es que gran parte del uso de RISC V no se basa en software común: hay cientos de chips RISC V que se están diseñando para IoT, aplicaciones industriales y otras aplicaciones integradas. Creemos que RISC V llegará a dominar este mercado. A menos que alguien presente un sistema operativo para Internet de las cosas (IoT), realmente no hay necesidad de una arquitectura de chip común para estos dispositivos. Y somos firmes creyentes de que nunca habrá un sistema operativo para IoT.
También es muy posible que algún día el entorno de software de RISC V converja en soluciones más compatibles. Esto llevará años y estará lleno de problemas: ¿alguien recuerda la incompatibilidad de la impresora y el controlador de la GPU? - pero todavía es probable.
En esta etapa, RISC V parece imparable. Esa es una buena cosa. Pero no es una solución única para todos, y encontrará su parte de problemas de crecimiento, y muchos de ellos tendrán lugar en torno a la compatibilidad del software. Esto no presenta la misma barrera que una vez lo hizo.
