D'abord sur OABI, EABI, EABI-hf: ce sont des ABIs, il y a exactement le même problème sur x86 selon qu'on utilise un compilateur Visual Studio ou un gcc, par exemple. Le CPU n'est pas directement concerné, sauf pour EABI-hf, qui se permet d'utiliser les registres des unités à virgule flottante directement (il faut que ces registres soient donc présents). Il me semble que maintenant tout le monde fait de l'EABI-hf, ce problème est donc largement réglé (sauf pour les gens qui font de l'embarqué avec des CPUs qui n'ont pas de FPU, mais ce n'est pas la question ici). Ce serait donc comme se plaindre qu'il y a des problèmes sur x86 quand on veut écrire du code qui tourne aussi bien sur un 486 que sur le dernier Core i7.
Ensuite sur la détection du matériel: ARM est effectivement uniquement une architecture CPU (comme x86), pas une architecture de machine (comme le "compatible PC"). Donc, c'est fourni sans BIOS ou UEFI, et surtout sans bus permettant d'énumérer les périphériques et de découvrir le matériel présent (sur un PC ce rôle est rempli en partie par le BIOS, et en partie par le bus PCI).
Enfin sur les versions de l'architecture matérielle: oui, il y en a plusieurs. Mais ça n'a dérangé personne de voir apparaître de nouvelles instructions (MMX, SSE, SSE2, ...) sur les processeurs x86. Ni de voir AMD développer son propre jeu d'instruction concurrent (3DNow!) ou décider de faire une version 64 bits (que Intel a ensuite cloné). Pourquoi chez ARM soudainement ça serait un problème? Il est normal qu'une architecture de CPU évolue à chaque génération.
Cependant, les choses avancent. Du côté de ARM, tout un tas de choses qui ne sont pas purement du CPU sont standardisées petit à petit: la MMU, un timer qui déclenche une interruption à intervalles réguliers, etc. Du côté de Linux, les applications et tout l'userspace fonctionnent sur toutes les machines (c'est la moindre des choses qu'on attend d'un OS: fournir une couche d'abstraction du matériel). Le noyau devrait pouvoir le faire aussi, normalement. Pour cela on a besoin d'un "device tree" qui décrit le matériel (à quelle adresse sont les différents périphériques, la mémoire, etc) et dans le cas de Linux, de drivers intégrés dans le noyau mainline. C'est surtout de ce côté que ça coince: il ne semble pas raisonable pour la plupart des constructeurs de devoir absolument stocker leurs drivers dans le dépôt Git de Linus et de devoir passer toutes les étapes de revue de code (les défenseurs de cette stratégie diront que c'est pour leur bien, que ça augmente la qualité du code et qu'en échange ils assureront la maintenance). Pour l'instant le support des différents systèmes ARM repose donc largement sur la communauté, mais c'est comme ça que Linux a pu se faire une place sur le marché du PC aussi, au moins au début.
Le "compatible Android" a déjà remplacé le "compatible PC" comme standard de machine le plus répandu. Que Linux n'arrive pas encore à s'y adapter, c'est un autre problème.
[^] # Re: Effet de mode?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal ARM vs Intel. Évalué à 8.
Faisons le point là-dessus.
D'abord sur OABI, EABI, EABI-hf: ce sont des ABIs, il y a exactement le même problème sur x86 selon qu'on utilise un compilateur Visual Studio ou un gcc, par exemple. Le CPU n'est pas directement concerné, sauf pour EABI-hf, qui se permet d'utiliser les registres des unités à virgule flottante directement (il faut que ces registres soient donc présents). Il me semble que maintenant tout le monde fait de l'EABI-hf, ce problème est donc largement réglé (sauf pour les gens qui font de l'embarqué avec des CPUs qui n'ont pas de FPU, mais ce n'est pas la question ici). Ce serait donc comme se plaindre qu'il y a des problèmes sur x86 quand on veut écrire du code qui tourne aussi bien sur un 486 que sur le dernier Core i7.
Ensuite sur la détection du matériel: ARM est effectivement uniquement une architecture CPU (comme x86), pas une architecture de machine (comme le "compatible PC"). Donc, c'est fourni sans BIOS ou UEFI, et surtout sans bus permettant d'énumérer les périphériques et de découvrir le matériel présent (sur un PC ce rôle est rempli en partie par le BIOS, et en partie par le bus PCI).
Enfin sur les versions de l'architecture matérielle: oui, il y en a plusieurs. Mais ça n'a dérangé personne de voir apparaître de nouvelles instructions (MMX, SSE, SSE2, ...) sur les processeurs x86. Ni de voir AMD développer son propre jeu d'instruction concurrent (3DNow!) ou décider de faire une version 64 bits (que Intel a ensuite cloné). Pourquoi chez ARM soudainement ça serait un problème? Il est normal qu'une architecture de CPU évolue à chaque génération.
Cependant, les choses avancent. Du côté de ARM, tout un tas de choses qui ne sont pas purement du CPU sont standardisées petit à petit: la MMU, un timer qui déclenche une interruption à intervalles réguliers, etc. Du côté de Linux, les applications et tout l'userspace fonctionnent sur toutes les machines (c'est la moindre des choses qu'on attend d'un OS: fournir une couche d'abstraction du matériel). Le noyau devrait pouvoir le faire aussi, normalement. Pour cela on a besoin d'un "device tree" qui décrit le matériel (à quelle adresse sont les différents périphériques, la mémoire, etc) et dans le cas de Linux, de drivers intégrés dans le noyau mainline. C'est surtout de ce côté que ça coince: il ne semble pas raisonable pour la plupart des constructeurs de devoir absolument stocker leurs drivers dans le dépôt Git de Linus et de devoir passer toutes les étapes de revue de code (les défenseurs de cette stratégie diront que c'est pour leur bien, que ça augmente la qualité du code et qu'en échange ils assureront la maintenance). Pour l'instant le support des différents systèmes ARM repose donc largement sur la communauté, mais c'est comme ça que Linux a pu se faire une place sur le marché du PC aussi, au moins au début.
Le "compatible Android" a déjà remplacé le "compatible PC" comme standard de machine le plus répandu. Que Linux n'arrive pas encore à s'y adapter, c'est un autre problème.