La empresa china especialista en chips T-Head, filial de Alibaba, ha portado una variante de Android 10 para la arquitectura abierta RISC-V. Repositorio: https://github.com/T-head-Semi/aosp-riscv
La parte buena de todo esto es que Risc-V funciona diferente de ARM en un sentido fundamental.
Cada empresa que licencia ARM, modifica la arquitectura para su interés, añadiendo instrucciones e incluso modificando las estándares, con lo cual cada versión tiene que mantener su propio port (cosa que pocas hacen a medio-largo plazo).
Risc-V está diseñado para que las instrucciones base sean pocas y sencillas (un RISC puro, al contrario que ARM) y el resto de necesidades se añada como aceleradores específicos en forma de extensiones (más o menos estándares). Así (teóricamente, veremos si con el tiempo se enguarra) un port de Risc-V se garantiza una mantenibilidad y facilidad de funcionar muchísimo mayor entre dispositivos basados en esta arquitectura (quizá no te use esta o esta otra extensión, pero la base es igual para todos).
O sea, muy fácil portar cualquier cosa a Risc-V y una vez portada, muy fácil de mantener y reusar en dispositivos más nuevos (tomar ventaja de las nuevas extensiones que se necesiten y listo).
#1 ¿Estás seguro de lo de las instrucciones? Cambiar eso implica modificar el núcleo.
Cosa diferente es cambiar los dispositivos que van alrededor del núcleo. Pero las instrucciones...
Por otro lado, la arquitectura ARM se ha limpiado mucho en la versión de 64 bits. Aunque también es cierto que Risc-V tiene un estándar para poder eliminar instrucciones que se consideren obsoletas y reemplazarlas por otras nuevas, y eso sí es una ventaja sobre ARM.
Cuenta las variantes (los match-)... y esas son las soportadas en linux, las no mantenidas o sin soporte upstream ni están ni se las espera.
El problema es que hay muchas especificaciones y para cada especificación "común", hay muchas implementaciones diferentes, lo que provoca problemas de compatibilidad incluso partiendo de las mismas especificaciones. Si además personalizas implementando cosas de tu parte...
De una diapositiva:
ARM cores: an actual implementation
▶ ARM Holdings plc then creates IP cores that implement the specification
▶ IP core = implementation in VHDL or Verilog of a block of hardware logic
▶ Examples:
ARM926 = implementation of ARMv5
ARM1176 = implementation of ARMv6
Cortex-A15 = implementation of ARMv7-A
Cortex-A53 = implementation of ARMv8-A
▶ Multiple possible implementations for the same architecture specification
▶ Example: all of Cortex-A5,7,8,9,12,15 implement the same ARMv7-A architecture
(with some additions in some cases)
▶ Cortex-A5 is a low-power lower-performance implementation, Cortex-A15 is a very
high-performance and more power hungry implementation.
▶ Difference in internal implementation: depth of the pipeline, out-of-order execution,
size of caches, etc.
▶ This is NOT hardware: ARM does not sell silicon
Y todo esto es hardware, pero eso tiene su reflejo en el software. Esa complejidad, Risc-V la desplaza a las extensiones que el fabricante quiera añadir, con lo cual, la implementación y el soporte base es común para todos los dispositivos Risc-V, evitando este infiernillo.
Espero que si, que en 64 bits hayan tomado un camino más racional. Por lo pronto, el M1 de apple ya tiene muchas particularidades sobre su arquitectura derivada, si se ha logrado arrancar linux ahí es porque ya había mucho trabajo detrás para conseguirlo con el soc para iphone que había sacado apple bastante antes, con el que comparte mucho; en palabras de Correlium, los que lo han realizado: "More work, much more work, needs to be done. As one of the programmers tweeted, "It'll take a while to upstream, it's a very promising port though." That's "because of the SoC being typical, more invasive kernel changes are needed."
#3 Vamos a ver... ARMv5 y ARMv6 son versiones que pueden considerarse obsoletas, y serían el equivalente del 386 y el 486: los nuevos son compatibles hacia atrás pero incluyen instrucciones nuevas. Hoy en día todos implementan ARMv7 o ARMv8.
Es que si nos ponemos así, podemos decir exactamente lo mismo de la arquitectura x86: hoy en día un núcleo Linux ya no puede funcionar en 386 y creo que tampoco en 486 porque exigen instrucciones de Pentium.
#4 Pero por otros temas. Evidentemente, linux no soporta 16 bits, por ejemplo, y el soporte a 32 bits cada día está más en duda si mantenerlo o quitarlo y es importante usar extensiones de instrucciones de cómputo vectorial y demás por cuestiones de rendimiento. A partir de ahí, funciona cualquier cosa...
Aquí no estamos hablando de aprovechar instrucciones nuevas, hablo de que cada implementación de una versión de arquitectura ARM es distinta en si misma y potencialmente incompatible, no porque introduzcan instrucciones propias (que también), sino porque pueden usar las comunes de maneras diferentes para exprimir rendimiento o dar capacidades que el estándar no tiene. La tentación de usar a la CISC y meter una instrucción con un direccionamiento más potente y complejo o que resuelva un problema concreto es muy grande.
#5 Pero 386 no está soportado desde hace tiempo. Y lo mismo con ARM. Sí, se soporta v5 y v6 (de hecho, la v6 creo que es por las Raspberry Pi 1, que su ARM no era v7), pero hoy en día lo que te venden son ARMv7 o superior (los Cortex son diseños V7 o V8).
Y esto es igual con el RISC-V, por cierto: la arquitectura básica no tiene ni siquiera "modo supervisor", por lo que un Linux normal no puede funcionar ahí (salvo que uses UserMode Linux, que tiene un montón de limitaciones), tienes que usar un núcleo que tenga esa extensión para poder meter un Linux en condiciones.
Además, y volviendo a tu comentario original, esto no es que el que compra el diseño le añada, quite o cambie instrucciones, sino que es simplemente la evolución de la arquitectura, a la que ARM, la empresa diseñadora, le va a añadiendo cosas con el tiempo y por eso "sube de versión". Que luego un fabricante compre un núcleo V7 en vez de V8 para ahorrarse pasta es equivalente a que una empresa se compre un Core Duo en lugar de un i5. Pero no "modifica la arquitectura en su propio interés, añadiendo instrucciones e incluso modificando las estándares", como decías en tu comentario.
#6 Pero no es por juegos de instrucciones (el 386 y el 486 apenas tienen instrucciones distintas), es por el modelo de memoria (el 486 tiene más salvaguardas y formas de acceder a la memoria que el 386; a partir de ahí hay mejoras, pero el modelo es similar). Del mismo modo que el 386 permite cosas que en las que el 286 está muy muy limitado.
Si es algo muy usado y está bien definido y las implementaciones son eficaces, terminarán pasando a ser estándares. Si resulta que el port para linux usa una extensión particular y tú quieres un chip que funcione en linux, implementarás esa extensión y ya tendrás el soporte "gratis".
A ver, no hablamos de ARM. Hablamos de qualcomm, de xiami, de apple... cojen el diseño y especificaciones de ARM v loquesea, retocan el diseño y siguen las especificaciones que les interesan, añaden cosas que necesitan y sacan su propia implementación de esa especificación. Y esa versión partirá del soporte linux que tenga la especificación base de referencia o del fabricante que haya abierto sus fuentes y tendrán que modificarla para que corra en la propia. El problema no es ARM, que saque una v3.5 y ya sea incompatible con la v3. Eso se da por hecho, cada versión, cada diseño, es una evolución del anterior (más continuísta o más rupturista). El problema son las implementaciones en hardware (y su soporte software), qualcomm v3 y nvidia v3 pueden necesitar cada una su propio código para que todo funcione como debe.
#7 El modelo de memoria del 486 es prácticamente idéntico al del 386. De hecho, el motivo de eliminar el soporte de 386 fue que el 486 tenía un montón de instrucciones atómicas nuevas que simplifican el código en SMP: https://www.osnews.com/story/26608/386-support-removed-from-linux/
Y una vez más: ni Qualcomm, ni Xiami, ni apple cambian instrucciones. Como mucho añadirán instrucciones específicas para módulos propios (lo que tampoco es realmente algo anormal, pues precisamente es la manera en que se trabaja en ARM: tienes un conjunto de instrucciones que están reservadas para manejar coprocesadores, y esas sí son "personalizables"), pero el conjunto de instrucciones es ARMv7 o ARMv8.
Es que si no, no pueden decir que eso es ARM. Será "parecido a ARM" como mucho.
#8 ¿Y qué son las primitivas SMP? ¿sabes para qué sirven? ¿por qué suponen una mejora considerable, suficiente como para dejar de lado el soporte a un sistema y apostar por el otro? ¿sabes la importancia de que sean atómicas?. Se trata precisamente de instrucciones para poder usar la memoria de manera más segura (atómicas para que no haya cosas que se ejecuten en mitad de una operación y haya problemas de accesos) en entornos multiproceso, lo cual es el escenario más común; se hace por razones prácticas y para evitar una complejidad aún mayor en el kernel. Igualmente, nada te impide coger un linux 3.7 o anterior y compilar para 386...
Vale, no cambies una instrucción, añade otra. Añade una de acceso a memoria, y úsala simpre porque es más efectiva o eficiente (y de paso, te ahorras el silicio que cuesta implementar la otra, que de todos modos no usas). Ya está un programa compilado para un soc ya no funciona en otro basado en la misma arquitectura y viceversa. ¿Te vale?. Estamos hablando de que ningún fabricante está obligado a implementar toda la especificación, ni implementarla de la misma manera. Que en el fondo compilas para esa arquitectura y ya está ¿no? pues si y no...
Mira, en el mundo embebido ni te garantizan poder usar los mismos periféricos, y esto lejos de los fabricantes de móviles y grandes inversiones en retocar las arquitecturas para rendir más que los demás:
>I am looking into using the ARM Cortex M family for a new project. I
>like the Cortex M series, since in "principle" code should be pretty
>simelar from one device to another, if you limit the functionality to
>the core and some limited periphials.
As things stand today, I would not expect the peripherals to be
compatible unless you are staying with a single vendor.
>So, if it is possible to define the allowed instruction set for the
>M0+, would it then be possible to scale up to a larger device (M0, M1,
>M3, M4) without recompiling core code?
>That would allow us to use a OS with a API layer (to provide
>flexibility between the periphial differences), and have the core code
>running with the same binary code across the M family?
>
>Anyone have practical experience with porting code this way?
Yes - We do recompile for different processors and chip vendors.
If you want your code to be 100% portable think of using a byte code
interpreter. (Forth, Java, Lua, .NET, etc.)
--
Roberto Waltman
Dices que es basado en ARMvX porque has usado las especificaciones de ARMvX. De hecho, cada fabricante le pone un nombre a sus chips, y no es sólo por mercadotecnia...
#9 Y yo discrepo. El modelo de memoria es el sistema de paginación y segmentación, y la protección entre zonas. Las instrucciones que realizan operaciones de lectura o escritura atómicas son independientes del modelo de memoria. Y por otro lado, no puedes "quitar el silicio que ocupaba la otra", porque entonces pierdes compatibilidad hacia atrás (las instrucciones no atómicas se usan para todo lo demás). Precisamente LA ventaja de RISC-V (en mi opinión) es que sí han dispuesto un mecanismo para poder eliminar instrucciones obsoletas, cosa que ningún otro procesador tiene.
Y respecto a tus citas: habla de PERIFÉRICOS, no de JUEGOS DE INSTRUCCIONES. Por otro lado, una vez más, si compilas para ARMv8 no serás compatible con versiones anteriores, pero si compilas para ARMv5 serás compatible con v5, v6, v7 y v8... ¡pero a nivel de instrucciones, no de periféricos! Los periféricos son otra historia, y lo dije en mi comentario anterior.
#10 ¿Me dices que las operaciones de lectura y escritura en memoria son del todo ajenas del modelo de memoria que tenga la máquina? ¿seguro que no dependen ni un poquitín?
Hablamos principalmente de fabricantes de móviles: adaptan el compilador y compilan para su nuevo soc, la compatibilidad hacia atrás les trae al pairo...
¿Y cómo se accede a los periféricos? ¿dónde viene definido? en las especificaciones de la arquitectura... el cableado, conectores y demás lo definen otros estándares (que arm puede seguir o no, pero que no se encarga de desarrollar).
#11 El que una instrucción sea o no atómica no depende del modelo de memoria que tenga por debajo, no. A lo que afecta es a la ejecución fuera de orden y a la ejecución especulativa.
#12 Afecta a que te genera problemas con los cambios de contexto en multiproceso (ni siquiera hace falta "especular"), afecta por ejemplo a accesos a las mismas y a contiguas regiones de memoria y por lo tanto problemas de coherencia de caché y problemas de rendimiento. No es lo mismo un modelo de memoria paginada que otra segmentada que una memoria unificada, pero lo ideal es que las operaciones sobre cada una sean atómicas para evitar los mismos problemas y en cada modelo se implementa de manera distinta. ¿Y dónde se define cómo se realiza todo eso? en las especificaciones de la arquitectura porque todo eso va implementado en hardware (que no implica que tengas que ver instrucciones para manejar eso, porque igual son mecanismos hardware, tú sólo ves las interrupciones de cuando se intenta acceder a datos fuera del segmento/página/etc).
Comentarios
La parte buena de todo esto es que Risc-V funciona diferente de ARM en un sentido fundamental.
Cada empresa que licencia ARM, modifica la arquitectura para su interés, añadiendo instrucciones e incluso modificando las estándares, con lo cual cada versión tiene que mantener su propio port (cosa que pocas hacen a medio-largo plazo).
Risc-V está diseñado para que las instrucciones base sean pocas y sencillas (un RISC puro, al contrario que ARM) y el resto de necesidades se añada como aceleradores específicos en forma de extensiones (más o menos estándares). Así (teóricamente, veremos si con el tiempo se enguarra) un port de Risc-V se garantiza una mantenibilidad y facilidad de funcionar muchísimo mayor entre dispositivos basados en esta arquitectura (quizá no te use esta o esta otra extensión, pero la base es igual para todos).
O sea, muy fácil portar cualquier cosa a Risc-V y una vez portada, muy fácil de mantener y reusar en dispositivos más nuevos (tomar ventaja de las nuevas extensiones que se necesiten y listo).
#1 ¿Estás seguro de lo de las instrucciones? Cambiar eso implica modificar el núcleo.
Cosa diferente es cambiar los dispositivos que van alrededor del núcleo. Pero las instrucciones...
Por otro lado, la arquitectura ARM se ha limpiado mucho en la versión de 64 bits. Aunque también es cierto que Risc-V tiene un estándar para poder eliminar instrucciones que se consideren obsoletas y reemplazarlas por otras nuevas, y eso sí es una ventaja sobre ARM.
#2 https://github.com/ARM-software/linux/tree/linux-4.1-mali/arch/arm
Cuenta las variantes (los match-)... y esas son las soportadas en linux, las no mantenidas o sin soporte upstream ni están ni se las espera.
El problema es que hay muchas especificaciones y para cada especificación "común", hay muchas implementaciones diferentes, lo que provoca problemas de compatibilidad incluso partiendo de las mismas especificaciones. Si además personalizas implementando cosas de tu parte...
De una diapositiva:
ARM cores: an actual implementation
▶ ARM Holdings plc then creates IP cores that implement the specification
▶ IP core = implementation in VHDL or Verilog of a block of hardware logic
▶ Examples:
ARM926 = implementation of ARMv5
ARM1176 = implementation of ARMv6
Cortex-A15 = implementation of ARMv7-A
Cortex-A53 = implementation of ARMv8-A
▶ Multiple possible implementations for the same architecture specification
▶ Example: all of Cortex-A5,7,8,9,12,15 implement the same ARMv7-A architecture
(with some additions in some cases)
▶ Cortex-A5 is a low-power lower-performance implementation, Cortex-A15 is a very
high-performance and more power hungry implementation.
▶ Difference in internal implementation: depth of the pipeline, out-of-order execution,
size of caches, etc.
▶ This is NOT hardware: ARM does not sell silicon
Y todo esto es hardware, pero eso tiene su reflejo en el software. Esa complejidad, Risc-V la desplaza a las extensiones que el fabricante quiera añadir, con lo cual, la implementación y el soporte base es común para todos los dispositivos Risc-V, evitando este infiernillo.
Espero que si, que en 64 bits hayan tomado un camino más racional. Por lo pronto, el M1 de apple ya tiene muchas particularidades sobre su arquitectura derivada, si se ha logrado arrancar linux ahí es porque ya había mucho trabajo detrás para conseguirlo con el soc para iphone que había sacado apple bastante antes, con el que comparte mucho; en palabras de Correlium, los que lo han realizado: "More work, much more work, needs to be done. As one of the programmers tweeted, "It'll take a while to upstream, it's a very promising port though." That's "because of the SoC being typical, more invasive kernel changes are needed."
PD: El pdf...
https://bootlin.com/pub/conferences/2017/lca/petazzoni-arm-introduction/petazzoni-arm-introduction.pdf
#3 Vamos a ver... ARMv5 y ARMv6 son versiones que pueden considerarse obsoletas, y serían el equivalente del 386 y el 486: los nuevos son compatibles hacia atrás pero incluyen instrucciones nuevas. Hoy en día todos implementan ARMv7 o ARMv8.
Es que si nos ponemos así, podemos decir exactamente lo mismo de la arquitectura x86: hoy en día un núcleo Linux ya no puede funcionar en 386 y creo que tampoco en 486 porque exigen instrucciones de Pentium.
#4 Pero por otros temas. Evidentemente, linux no soporta 16 bits, por ejemplo, y el soporte a 32 bits cada día está más en duda si mantenerlo o quitarlo y es importante usar extensiones de instrucciones de cómputo vectorial y demás por cuestiones de rendimiento. A partir de ahí, funciona cualquier cosa...
https://hackaday.com/2020/07/08/the-latest-linux-on-a-floppy-in-a-486/
Aquí no estamos hablando de aprovechar instrucciones nuevas, hablo de que cada implementación de una versión de arquitectura ARM es distinta en si misma y potencialmente incompatible, no porque introduzcan instrucciones propias (que también), sino porque pueden usar las comunes de maneras diferentes para exprimir rendimiento o dar capacidades que el estándar no tiene. La tentación de usar a la CISC y meter una instrucción con un direccionamiento más potente y complejo o que resuelva un problema concreto es muy grande.
#5 Pero 386 no está soportado desde hace tiempo. Y lo mismo con ARM. Sí, se soporta v5 y v6 (de hecho, la v6 creo que es por las Raspberry Pi 1, que su ARM no era v7), pero hoy en día lo que te venden son ARMv7 o superior (los Cortex son diseños V7 o V8).
Y esto es igual con el RISC-V, por cierto: la arquitectura básica no tiene ni siquiera "modo supervisor", por lo que un Linux normal no puede funcionar ahí (salvo que uses UserMode Linux, que tiene un montón de limitaciones), tienes que usar un núcleo que tenga esa extensión para poder meter un Linux en condiciones.
Además, y volviendo a tu comentario original, esto no es que el que compra el diseño le añada, quite o cambie instrucciones, sino que es simplemente la evolución de la arquitectura, a la que ARM, la empresa diseñadora, le va a añadiendo cosas con el tiempo y por eso "sube de versión". Que luego un fabricante compre un núcleo V7 en vez de V8 para ahorrarse pasta es equivalente a que una empresa se compre un Core Duo en lugar de un i5. Pero no "modifica la arquitectura en su propio interés, añadiendo instrucciones e incluso modificando las estándares", como decías en tu comentario.
#6 Pero no es por juegos de instrucciones (el 386 y el 486 apenas tienen instrucciones distintas), es por el modelo de memoria (el 486 tiene más salvaguardas y formas de acceder a la memoria que el 386; a partir de ahí hay mejoras, pero el modelo es similar). Del mismo modo que el 386 permite cosas que en las que el 286 está muy muy limitado.
Si es algo muy usado y está bien definido y las implementaciones son eficaces, terminarán pasando a ser estándares. Si resulta que el port para linux usa una extensión particular y tú quieres un chip que funcione en linux, implementarás esa extensión y ya tendrás el soporte "gratis".
A ver, no hablamos de ARM. Hablamos de qualcomm, de xiami, de apple... cojen el diseño y especificaciones de ARM v loquesea, retocan el diseño y siguen las especificaciones que les interesan, añaden cosas que necesitan y sacan su propia implementación de esa especificación. Y esa versión partirá del soporte linux que tenga la especificación base de referencia o del fabricante que haya abierto sus fuentes y tendrán que modificarla para que corra en la propia. El problema no es ARM, que saque una v3.5 y ya sea incompatible con la v3. Eso se da por hecho, cada versión, cada diseño, es una evolución del anterior (más continuísta o más rupturista). El problema son las implementaciones en hardware (y su soporte software), qualcomm v3 y nvidia v3 pueden necesitar cada una su propio código para que todo funcione como debe.
#7 El modelo de memoria del 486 es prácticamente idéntico al del 386. De hecho, el motivo de eliminar el soporte de 386 fue que el 486 tenía un montón de instrucciones atómicas nuevas que simplifican el código en SMP: https://www.osnews.com/story/26608/386-support-removed-from-linux/
Y una vez más: ni Qualcomm, ni Xiami, ni apple cambian instrucciones. Como mucho añadirán instrucciones específicas para módulos propios (lo que tampoco es realmente algo anormal, pues precisamente es la manera en que se trabaja en ARM: tienes un conjunto de instrucciones que están reservadas para manejar coprocesadores, y esas sí son "personalizables"), pero el conjunto de instrucciones es ARMv7 o ARMv8.
Es que si no, no pueden decir que eso es ARM. Será "parecido a ARM" como mucho.
#8 ¿Y qué son las primitivas SMP? ¿sabes para qué sirven? ¿por qué suponen una mejora considerable, suficiente como para dejar de lado el soporte a un sistema y apostar por el otro? ¿sabes la importancia de que sean atómicas?. Se trata precisamente de instrucciones para poder usar la memoria de manera más segura (atómicas para que no haya cosas que se ejecuten en mitad de una operación y haya problemas de accesos) en entornos multiproceso, lo cual es el escenario más común; se hace por razones prácticas y para evitar una complejidad aún mayor en el kernel. Igualmente, nada te impide coger un linux 3.7 o anterior y compilar para 386...
Vale, no cambies una instrucción, añade otra. Añade una de acceso a memoria, y úsala simpre porque es más efectiva o eficiente (y de paso, te ahorras el silicio que cuesta implementar la otra, que de todos modos no usas). Ya está un programa compilado para un soc ya no funciona en otro basado en la misma arquitectura y viceversa. ¿Te vale?. Estamos hablando de que ningún fabricante está obligado a implementar toda la especificación, ni implementarla de la misma manera. Que en el fondo compilas para esa arquitectura y ya está ¿no? pues si y no...
Mira, en el mundo embebido ni te garantizan poder usar los mismos periféricos, y esto lejos de los fabricantes de móviles y grandes inversiones en retocar las arquitecturas para rendir más que los demás:
https://www.embeddedrelated.com/showthread/comp.arch.embedded/136223-1.php
Kvik wrote:
>I am looking into using the ARM Cortex M family for a new project. I
>like the Cortex M series, since in "principle" code should be pretty
>simelar from one device to another, if you limit the functionality to
>the core and some limited periphials.
As things stand today, I would not expect the peripherals to be
compatible unless you are staying with a single vendor.
>So, if it is possible to define the allowed instruction set for the
>M0+, would it then be possible to scale up to a larger device (M0, M1,
>M3, M4) without recompiling core code?
>That would allow us to use a OS with a API layer (to provide
>flexibility between the periphial differences), and have the core code
>running with the same binary code across the M family?
>
>Anyone have practical experience with porting code this way?
Yes - We do recompile for different processors and chip vendors.
If you want your code to be 100% portable think of using a byte code
interpreter. (Forth, Java, Lua, .NET, etc.)
--
Roberto Waltman
Dices que es basado en ARMvX porque has usado las especificaciones de ARMvX. De hecho, cada fabricante le pone un nombre a sus chips, y no es sólo por mercadotecnia...
#9 Y yo discrepo. El modelo de memoria es el sistema de paginación y segmentación, y la protección entre zonas. Las instrucciones que realizan operaciones de lectura o escritura atómicas son independientes del modelo de memoria. Y por otro lado, no puedes "quitar el silicio que ocupaba la otra", porque entonces pierdes compatibilidad hacia atrás (las instrucciones no atómicas se usan para todo lo demás). Precisamente LA ventaja de RISC-V (en mi opinión) es que sí han dispuesto un mecanismo para poder eliminar instrucciones obsoletas, cosa que ningún otro procesador tiene.
Y respecto a tus citas: habla de PERIFÉRICOS, no de JUEGOS DE INSTRUCCIONES. Por otro lado, una vez más, si compilas para ARMv8 no serás compatible con versiones anteriores, pero si compilas para ARMv5 serás compatible con v5, v6, v7 y v8... ¡pero a nivel de instrucciones, no de periféricos! Los periféricos son otra historia, y lo dije en mi comentario anterior.
#10 ¿Me dices que las operaciones de lectura y escritura en memoria son del todo ajenas del modelo de memoria que tenga la máquina? ¿seguro que no dependen ni un poquitín?
Hablamos principalmente de fabricantes de móviles: adaptan el compilador y compilan para su nuevo soc, la compatibilidad hacia atrás les trae al pairo...
¿Y cómo se accede a los periféricos? ¿dónde viene definido? en las especificaciones de la arquitectura... el cableado, conectores y demás lo definen otros estándares (que arm puede seguir o no, pero que no se encarga de desarrollar).
#11 El que una instrucción sea o no atómica no depende del modelo de memoria que tenga por debajo, no. A lo que afecta es a la ejecución fuera de orden y a la ejecución especulativa.
#12 Afecta a que te genera problemas con los cambios de contexto en multiproceso (ni siquiera hace falta "especular"), afecta por ejemplo a accesos a las mismas y a contiguas regiones de memoria y por lo tanto problemas de coherencia de caché y problemas de rendimiento. No es lo mismo un modelo de memoria paginada que otra segmentada que una memoria unificada, pero lo ideal es que las operaciones sobre cada una sean atómicas para evitar los mismos problemas y en cada modelo se implementa de manera distinta. ¿Y dónde se define cómo se realiza todo eso? en las especificaciones de la arquitectura porque todo eso va implementado en hardware (que no implica que tengas que ver instrucciones para manejar eso, porque igual son mecanismos hardware, tú sólo ves las interrupciones de cuando se intenta acceder a datos fuera del segmento/página/etc).
#13 Y luego dicen que YO hago honor a mi nick...