Perso j'ai du mal à faire la différence entre "matériel" et "logiciel" (c'est une séparation arbitraire sur ce qu'on fait en soft ou en hard, pour des questions souvent de coût), donc que mon BIOS soit libre alors que ma carte-mère ne l'est pas me fait "pshit" (si il y a une back-door, elle sera dans le matériel de toutes façons).
Je rejoins Zenitram sur la distinction purement arbitraire entre matériel et logiciel. Un ami qui travaille dans une entreprise qui conçoit des processeurs m'a expliqué que l'électronique est entièrement générée par un compilateur. La conception en elle-même consiste à écrire du code qui ressemble à du code système.
Ainsi, dans le cas de processeurs ARM, on peut acheter soit une licence pour le jeux d'instructions (ISA ARM), soit une licence pour une implémentation qui est fournie sous forme compilée. Il est alors possible d'intégrer ce "binaire" au sein de sa propre puce en ajoutant ses propres composants autour.
Il est ainsi tout à fait possible de coder des fonctionnalités en dur dans les processeurs. De ce que j'ai compris, le nombre de lignes de code très important et les cycles de développement très courts font qu'il y a quantité de bugs dans le "matériel". Le firmware/micro-code est un moyen de corriger ces bugs, soit en le contournant, soit en le masquant.
La différence entre code logiciel et code matériel est donc purement arbitraire.
[^] # Re: Manger sa propre nourriture
Posté par Chuck #1 . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à 10.
Je rejoins Zenitram sur la distinction purement arbitraire entre matériel et logiciel. Un ami qui travaille dans une entreprise qui conçoit des processeurs m'a expliqué que l'électronique est entièrement générée par un compilateur. La conception en elle-même consiste à écrire du code qui ressemble à du code système.
Ainsi, dans le cas de processeurs ARM, on peut acheter soit une licence pour le jeux d'instructions (ISA ARM), soit une licence pour une implémentation qui est fournie sous forme compilée. Il est alors possible d'intégrer ce "binaire" au sein de sa propre puce en ajoutant ses propres composants autour.
Il est ainsi tout à fait possible de coder des fonctionnalités en dur dans les processeurs. De ce que j'ai compris, le nombre de lignes de code très important et les cycles de développement très courts font qu'il y a quantité de bugs dans le "matériel". Le firmware/micro-code est un moyen de corriger ces bugs, soit en le contournant, soit en le masquant.
La différence entre code logiciel et code matériel est donc purement arbitraire.
Cette signature est publiée sous licence WTFPL