Bonjour,
Pour ma gourverne personnelle j'aimerais savoir comment font les sociétés qui livrent des briques logicielles sous forme de librairies lorsqu'elle ne veulent pas livrer le code (code C par exemple)
Sous quel format sont les fichiers?
Comment compiler lorsqu'on ne connait pas la cible? (processeur embarqué, PC, big ou little endian ...)?
Compilation par famille de processeurs? (donc de nombreuses version de lib?)
Quel "compilateur" utiliser?
Merci
Salut.
Les fichiers sont sous forme de bibliothèques (librairies étant la fausse traduction de l'anglais library, qui veut bien dire bibliothèque).Sous quel format sont les fichiers?
Sous Windows ce sont les extensions .dll ou .lib. Sous unix ce sont les fichiers .so ou .a mais l'extension n'a aucune importance. Le contenu de cette bibliothèque est formaté selon le type d'environement: elf ou a.out (et d'autres encore) sous UNIX, je crois exe32 ou exe64 pour windows.
Ces bibliothèques contiennent une section définissant leurs points d'entrées, ce qui correspondrait en gros à la déclaration de la fonction avec l'endroit où la trouver dans la bibliothèque. Google avec "édition dynamique de lien" si tu veux plus d'info.
Effectivement, tu dois être capable de fournir autant de version de bibliothèque binaire que de familles de processeur que tu veux supporter. Pour Windows ce n'est pas trop compliqué étant donné que seul les INTEL x86 et leurs clônes sont supportés, donc une seule famille. Chez les UNIX (et particulièrement LINUX), c'est effectivement plus compliqué, mais en soutenant les familles principales comme SPARC, POWERPC et x86 bien-sûr, je pense que tu réponds à 90% de la demande. Pour les domaines plus varié comme le monde de l'embarqué, là ça l'est bien plus...Comment compiler lorsqu'on ne connait pas la cible? (processeur embarqué, PC, big ou little endian ...)?
Compilation par famille de processeurs? (donc de nombreuses version de lib?)
Un petit détail quand même, tu peux fourir une bibliothèque qui marchera sur le plus simple des représentants de la famille que tu veuilles supporter, ou un binaire contenant le même code optimisé pour différent représentant de la famille. Par exemple, une bibliothèque compilée pour un 386 tournera sur tout les représentants x86, XEON quad core compris, mais ne bénificiera pas des optimisations propres aux derniers représentants de la famille, et plus grave encore sans utiliser les nouvelles instructions câblées dans les processeurs. La deuxième solution palie à ce problème au prix d'un binaire bien plus gros (autant de fois que d'optimisations).
vaste question, dépends obligatoirement de:Quel "compilateur" utiliser?
1°) L'environnement logiciel cîble (système d'exploitation + bibliothèque standard + format binaire)
2°) La cîble matérielle (= famille de processeur)
Auquels viennent s'ajouter des critères commes:
3°) La portabilité: si on veut utiliser le même compilateur pour différentes plateformes.
4°) Le budget,
5°) Le niveau de conformité avec des standards...
6°) Favorise-t'on les performances ou la sécurité...
Merci pour la reponse, ca confirme ce que je pensais. Contrairement au VHDL ou on peut avoir une compilation intermedaire (synthese: transforme le programme en fonctions de base: And, OR, Not ...), en informatique on n'a pas ce niveau intermedaire. Donc au minimum la famille et encore c'est pas optimisé.
Une première réponse:
Tu retrouves ce type de fonctionnement avec JAVA (et peut-être d'autres langages) où le code
source est transformé en un pseudo-code qui sera interprété par un machine virtuelle. Ainsi le même pseudo-code compilé JAVA peut s'exécuter sur n'importe quelle plateforme (matérielle + logiciel) sur laquelle il existe une machine virtuelle. Mais celà se fait au détriment des performances (tu ajoutes une couche), de plus en pratique on observe souvent des comportements différents entre des plate-formes différentes, ce qui peut poser des problèmes. Enfin, ma très petite expérience d'interfacer du JAVA avec des langages compilés, c'est vraiment la prise de tête...
Une deuxième réponse:
Beaucoup de personnes (et moi également) dise que c'est le rôle du langage C car il permet de décrire tout ce que tu peux désirer faire avec un processeur en te cachant comment ces fonctionnalitées son effectivement câblées dans le processeur cîble. De plus, le C est le langage universel, je ne connaîs pas de processeur (du simple pic16f84 au rutilant processeur d'un super calculateur) qui ne possède pas au moins un compilateur C, et il en va de même pour les plateformes logicielles. Et à mon humble avis, tant que les processeurs seront ce qu'ils sont (et je pense que il y a le temps avant que les processeurs quantiques soient réellement disponibles), le C gardera ce statut.
Une conclusion personelle:
Je ne vois pas d'autre utilité à ce langage universel hypotétique d'écrire une fois un code pour plusieurs cîbles différentes: c'est ce que l'on appelle la portabilité. Et c'est un paramètre à prendre en compte au tout début de la réflexion, puisque les cîbles envisagés vont forcement restreindre le choix des outils utilisables (compilateurs et bibliothèques tierces), de plus celà va induire une manière d'écrire ton code. Heureusement, une plus ou moins grande portabilité est possible grâce à certains concepts comme POSIX, certains langages comme le C (portabilité de sources) ou le JAVA (portabilité du pseudo-code), certaines bibliothèques (bibliothèque standard, STL, Qt, gtk ...), et tu peux même parfois utiliser le même compilateur pour tout plein de plateforme différente: par exemple GCC a une liste impressionante de compatibilité sans avoir à rougir (au niveau perf ou conformité aux standards) face à ses concurrent payants.
En espérant que celà apporte un peu plus d'eau à ton moulin.
Ok pour les explications mais comment font les sociétés qui livrent des IP s'ils ne veulent pas livrer le source?
Je ne sais pas ce que tu entends par "livrer des IP", mais suivant le marché que tu vises, tu adoptes la stratégie le plus adaptée, ou pas de stratégie du tout et tu ne supportes un seul système.
un IP (Intellectual Property) est soit un source soit une librairie livrée par une société. (on appelle aussi cela un core en elec num FPGA ou ASIC)
Par exemple une stack TCP/IP est une IP tres classique. De meme qu'un codeur MPEG ou un FEC (correction d'erreur)
