quand j'installe ma distrib, déjà elle tourne sur n'importe quelle variation (du moins beaucoup) de ix86 sans problème
Le plus petit dénominateur commun… ;-) Pour ix86, c'est souvent i586 de nos jours, notamment car NPTL ne supporte pas i386 (ni i486 IIRC).
Et comme tu dis, ce n ́est pas optimisé. Exit l ́accélération SSE pour le calcul de hash ; exit l ́accélération SSE3 pour le calcul 3DES… (exemples ! )
Certains programmes ont cependant une détection à l ́exécution pour utiliser certaines routines ou d'autres en fonction du CPU (eg. ffmpeg, IIRC).
Pourquoi un compilo pour Cortex-M0 avec sa libc associée ne conviendrait pas pour la plupart des développements sur Cortex-M3?
Si tu considères une famille de CPU ARM, alors oui, une toolchain ciblant le plus petit dénominateur commun de cette famille va générer du code tournant sur tous les CPUs de cette famille, même si de façon non-optimale dans la plupart des cas. En fait, le compilo, c ́est pas trop grave, avec des flags de compil, on peut choisir un autre processeur. Par contre, la libc, une fois compilée, c ́est marre.
Dans le monde de l ́embarqué, les resources sont souvents contraintes, et notamment l'alimentation pour les mobiles, par exemple. Faire tourner du code optimisé pour le processeur réellement utilisé, ça peut faire gagner quelques miliwatt par-ci, par-là, et pof ! deux heures d'autonomie supplémentaire !
Après, il peut y avoir des flags de compil' pour le soft-float/hard-float par exemple.
Avec gcc, on peut (même si c ́est loin d ́être trivial) compiler une toolchain 'multilib' qui utilise les flags de compil pour savoir quelle libc utiliser. Reste qu'il faut quand même compiler la libc autant de fois qu'il y a de combinaisons possibles de ces flags de compil.…
[^] # Re: Libc
Posté par ymorin . En réponse au journal Chaine(s) de compilation ARM. Évalué à 3.
Le plus petit dénominateur commun… ;-) Pour ix86, c'est souvent i586 de nos jours, notamment car NPTL ne supporte pas i386 (ni i486 IIRC).
Et comme tu dis, ce n ́est pas optimisé. Exit l ́accélération SSE pour le calcul de hash ; exit l ́accélération SSE3 pour le calcul 3DES… (exemples ! )
Certains programmes ont cependant une détection à l ́exécution pour utiliser certaines routines ou d'autres en fonction du CPU (eg. ffmpeg, IIRC).
Si tu considères une famille de CPU ARM, alors oui, une toolchain ciblant le plus petit dénominateur commun de cette famille va générer du code tournant sur tous les CPUs de cette famille, même si de façon non-optimale dans la plupart des cas. En fait, le compilo, c ́est pas trop grave, avec des flags de compil, on peut choisir un autre processeur. Par contre, la libc, une fois compilée, c ́est marre.
Dans le monde de l ́embarqué, les resources sont souvents contraintes, et notamment l'alimentation pour les mobiles, par exemple. Faire tourner du code optimisé pour le processeur réellement utilisé, ça peut faire gagner quelques miliwatt par-ci, par-là, et
pof !deux heures d'autonomie supplémentaire !Avec gcc, on peut (même si c ́est loin d ́être trivial) compiler une toolchain 'multilib' qui utilise les flags de compil pour savoir quelle libc utiliser. Reste qu'il faut quand même compiler la libc autant de fois qu'il y a de combinaisons possibles de ces flags de compil.…