Discussion :

[dfg]

Bonjour,

Parfois, la compilation de certaines intructions dans un certain langage (C par exemple) produit des comportements différents selon la plateforme et le compilateur utilisé.

Cela est-il dû uniquement au fait que chaque compilateur a son propre runtime, ou peut-il y avoir d'autres raisons (en restant dans les différences entre compilateurs).

Formulé autrement : la spécification d'un langage est-elle implémentée entièrement par le runtime (la bibliothèque d'exécution, i.e. la base du langage pour le compilateur considéré).

Merci !

[gorgonite]

tu dois confondre runtime et lib standard

effectivement, selon les langages, les normes sont plus ou respectées (regardes les différences entre gnu c++ ; vs c++ ; comeau c++), et les lib standards sont plus ou moins optimisées
ça peut faire une grosse différence au final, alors qu'au premier abord on aurait pu se dire qu'en respectant les normes ou en prenant des lib "multi-plateformes" tout aurait été pareil

[dfg]

merci gorgonite d'avoir répondu,

c'est vrai que je vois mal la limite entre la bibliothèque standard et le runtime.
En gros la bibliothèque implémente les fonctions standards, mais théoriquement on peut changer de bibliothèque pour un même compilo.
Par contre le runtime implémente les types de base, mots réservés et opérateurs. Donc il est plus proche du compilateur.

Je fait cette distinction au fait qu'on peut créer un programme sans appeler aucune fonction de la bibliothèque standard, si on veut. Par contre on aura toujours types de base, mots réservés et opérateurs sans rien inclure comme header (en gardant en tête l'exemple du langage C).

Où est-ce que je me trompe ?

[gorgonite]

Par contre le runtime implémente les types de base, mots réservés et opérateurs. Donc il est plus proche du compilateur.

Je fait cette distinction au fait qu'on peut créer un programme sans appeler aucune fonction de la bibliothèque standard, si on veut. Par contre on aura toujours types de base, mots réservés et opérateurs sans rien inclure comme header (en gardant en tête l'exemple du langage C).

Où est-ce que je me trompe ?

effectivement, on peut se passer de la lib standard si l'on a écrit la sienne...
en revanche, je ne vois toujours pas le rapport entre la grammaire du langage et le runtime

perso, j'aurais plutôt situé le runtime au niveau des interprètes de bytecode, ou des interprètes tout court...
par exemple le GC fait parti du Runtime .Net, mais pas de CLI

[dfg]

en revanche, je ne vois toujours pas le rapport entre la grammaire du langage et le runtime

perso, j'aurais plutôt situé le runtime au niveau des interprètes de bytecode, ou des interprètes tout court...
par exemple le GC fait parti du Runtime .Net, mais pas de CLI

Ben là tu parles du runtime environment c'est à dire la machine virtuelle.
Et quand tu dis "interprètes tout court" tu parles des shells ?

Le runtime dont je parle c'est le runtime library.

En fait là je me base beaucoup sur wikipédia vu qu'il y a peu de ressources sur le net à propos de qu'est-ce que le runtime, ou quelle est la différence entre runtime et VM. Et même sur wiki c'est flou...

[gorgonite]

Ben là tu parles du runtime environment c'est à dire la machine virtuelle.

Le runtime dont je parle c'est le runtime library.

la runtime library est utilisée par le runtime environment...
j'ai déjà écrit un compilateur vers code natif, et je ne vois vraiment pas à quoi peut correspondre cette notion de runtime sur "vrais langages compilés"

En fait là je me base beaucoup sur wikipédia vu qu'il y a peu de ressources sur le net à propos de qu'est-ce que le runtime, ou quelle est la différence entre runtime et VM. Et même sur wiki c'est flou...

flou et pas toujours rigoureux

[dfg]

En fait je viens de trouver un truc intéressant, toujours sur Wikipédia :

While not standardized, C programs may depend on a runtime library of routines which contain code the compiler uses at runtime. The code that initializes the process for the operating system, for example, before calling main(), is implemented in the C Run-Time Library for a given vendor's compiler. The Run-Time Library code might help with other language feature implementations, like handling uncaught exceptions or implementing floating point code.

The C standard library only documents that the specific routines mentioned in this article are available, and how they behave. Because the compiler implementation might depend on these additional implementation-level functions to be available, it is likely the vendor-specific routines are packaged with the C Standard Library in the same module, because they're both likely to be needed by any program built with their toolset.

Though often confused with the C Standard Library because of this packaging, the C Runtime Library is not a standardized part of the language and is vendor-specific.

http://en.wikipedia.org/wiki/C_stand...port_libraries

J'en comprends que le C est plus ou moins managé à bas niveau

Donc si on se fie à cette citation j'était complètement à coté de la plaque en ce qui concerne la grammaire du langage, comme tu l'as dit.

Et pour essayer de répondre à ma toute première question je vais dire que oui, les compilos implémentent à leur manière la base du langage (disons lorsque les specs n'ont pas envisagé certains cas), mais que par ailleurs il y a aussi la runtime library qui fournit des mécanismes pour gérer le code au moment de l'exécution. Et cette runtime library dépend totalement du compilateur.

[gorgonite]

j'ai surtout l'impression que pour eux une "runtime library" c'est la lib standard + quelques trucs proprio qui seront probablement utilsés par leurs clients...

enfin, je pense qu'on devrait attendre JMB qui est plus au point sur ce genre de conventions

[dfg]

Merci pour tes réponses gorgonites.
En espérant que JMB passera par là ...

[souviron34]

je crois qu'il y a plusieurs points à éclaircir dans ton esprit :

1. Il y a différents paradigmes de langages : langages compilés (le code produit est directement des instructions machine), langages interprétés (le "code" est un texte interprétré au runtime).
   
2. la compilation du code d'un langage compilé peut se passer avec des bilbiothèques statiques (auquel cas le code de la bibliothèque est recopié dans le binaire du programme), ou des bibliothèques dynamiques (auquel cas c'est l'adresse de la fonction de la bibliothèque qui est copiée dans le binaire).

Donc , dans le cas d'un langage compilé, avec des bibliothèques statiques, le code binaire en ressortant est une série pure d'instructions machine, qui se déroulent les unes après les autres. Quand on le lance (runtime), on ne fait appel qu'aux primitives système.

Si donc il y a une différence d'exécution, cela est dû uniquement au système (mémoire, vitesse des disques, du bus, taille du swap, etc etc..).

Dans le cas d'un langage compilé avec usage de bibliothèques dynamiques, il peut en plus y avoir l'influence de l'implantation de cette bibliothèque au runtime.

Dans le cas des langages interprétés, cela dépend entièrement de l'implantation et des ressources (mémoire, et etc..) au runtime.

[dfg]

je crois qu'il y a plusieurs points à éclaircir dans ton esprit :

1. Il y a différents paradigmes de langages : langages compilés (le code produit est directement des instructions machine), langages interprétés (le "code" est un texte interprétré au runtime).
   
2. la compilation du code d'un langage compilé peut se passer avec des bilbiothèques statiques (auquel cas le code de la bibliothèque est recopié dans le binaire du programme), ou des bibliothèques dynamiques (auquel cas c'est l'adresse de la fonction de la bibliothèque qui est copiée dans le binaire).

Donc , dans le cas d'un langage compilé, avec des bibliothèques statiques, le code binaire en ressortant est une série pure d'instructions machine, qui se déroulent les unes après les autres. Quand on le lance (runtime), on ne fait appel qu'aux primitives système.

Si donc il y a une différence d'exécution, cela est dû uniquement au système (mémoire, vitesse des disques, du bus, taille du swap, etc etc..).

Dans le cas d'un langage compilé avec usage de bibliothèques dynamiques, il peut en plus y avoir l'influence de l'implantation de cette bibliothèque au runtime.

Dans le cas des langages interprétés, cela dépend entièrement de l'implantation et des ressources (mémoire, et etc..) au runtime.

J'ai connaissance des paradigmes dont tu parles, et en effet je pense qu'il y aurait quelque chose à creuser du côté de la liaison dynamique, mais je sais pas du tout comment le processus de liaison dynamique se déroule à très bas niveau.

Mais même en mode de liaison statique, les différences auxquelles je pensais sont des différences dont j'ai entendu parler mais dont je n'ai pas d'exemple à portée. Ils concernent des astuces du type enchaînement d'opérateurs d'incrémentation sur une même ligne d'instructions, enchainement dont les priorités ne seraient pas clairement définies (Il paraît même qu'il ya des concours sur ce genre d'astuces qui s'apparentent plus à de la programmation manuellement assombrie qu'à autre chose).

En fait ma question porte essentiellement sur les langages compilés car ils sont censés ne rien gérer au moment de l'exécution, donc il me paraît bizarre que leurs compilateurs prennent en considération une bibliothèque d'exécution. (gcc contient une runtime library).

[souviron34]

Mais même en mode de liaison statique, les différences auxquelles je pensais sont des différences dont j'ai entendu parler mais dont je n'ai pas d'exemple à portée. Ils concernent des astuces du type enchaînement d'opérateurs d'incrémentation sur une même ligne d'instructions, enchainement dont les priorités ne seraient pas clairement définies (Il paraît même qu'il ya des concours sur ce genre d'astuces qui s'apparentent plus à de la programmation manuellement assombrie qu'à autre chose).

"obfuscated code"

ça ne change STRICTEMENT RIEN à la vitesse d'éxécution. Cela complexifie (dramatiquement) la lecture du code, mais le compilo se débrouille, et produit un code strictement identique que si c'était écrit normalement.

Par contre, il est bien évident que si les ordres ne sont pas correctement définis, cela peut se modifier.

Mais attends.

Si tu compares le même binaire porté sur différentes machines, liés avec des bibliothèques statiques, les seules différences seront les accès au système.

Si maintenant on parle du même code source, compilé sur différentes machines, bien sûr là ça dépend des bibliothèques et de leur implantation.

En fait ma question porte essentiellement sur les langages compilés car ils sont censés ne rien gérer au moment de l'exécution, donc il me paraît bizarre que leurs compilateurs prennent en considération une bibliothèque d'exécution. (gcc contient une runtime library).

encore une fois parce que tu peux te lier dynamiquement et non pas statiquement.

Statiquement le code de la biblothèque est inclus dans le binaire.

Dynamiquement, le compilateur insère à la place de l'appel de la fonction un "jump adresse (fichier bibliothèque +offset fonction)" et non le code lui-même. Donc, au run-time, tu prends effectivement le code de la bibliothèque installée sur le système.

[dfg]

Merci de tes réponses, souviron34.

"obfuscated code"

ça ne change STRICTEMENT RIEN à la vitesse d'éxécution. Cela complexifie (dramatiquement) la lecture du code, mais le compilo se débrouille, et produit un code strictement identique que si c'était écrit normalement.

Par contre, il est bien évident que si les ordres ne sont pas correctement définis, cela peut se modifier.

Mais attends.

Si tu compares le même binaire porté sur différentes machines, liés avec des bibliothèques statiques, les seules différences seront les accès au système.

Si maintenant on parle du même code source, compilé sur différentes machines, bien sûr là ça dépend des bibliothèques et de leur implantation.

Pour tout ça je suis tout à fait d'accord avec toi.

encore une fois parce que tu peux te lier dynamiquement et non pas statiquement.

Statiquement le code de la biblothèque est inclus dans le binaire.

Dynamiquement, le compilateur insère à la place de l'appel de la fonction un "jump adresse (fichier bibliothèque +offset fonction)" et non le code lui-même. Donc, au run-time, tu prends effectivement le code de la bibliothèque installée sur le système.

Là tu sous-entends que tout ce qui pourrait être géré au runtime ne concernerait finalement que les problèmes de laisons de bibliothèques dynamiques.

Mais je pense qu'il doit y avoir autre chose.
Je pense même que ces considérations n'entrent pas en compte, car les bibliothèques sont dynamiques, mais la liaison est statique.

Les deux seules définitions que j'ai trouvé sur le Net à propos de runtime library (dont l'une s'inspire de l'autre...) :

http://www.knowledgerush.com/kr/ency...ntime_library/
http://en.wikipedia.org/wiki/Runtime_library

Pour celle de wikipédia, il faut voir aussi la page discussion qui en dit long sur les incertitudes qui règnent...

Quoi qu'il en soit, je pense avoir eu réponse à ma question initiale. Concernant la runtime library je vais creuser encore un peu puis éventuellement poser une question sur le forum C qui doit être plus calé la dessus.

[souviron34]

Là tu sous-entends que tout ce qui pourrait être géré au runtime ne concernerait finalement que les problèmes de laisons de bibliothèques dynamiques.

Mais je pense qu'il doit y avoir autre chose.
Je pense même que ces considérations n'entrent pas en compte, car les bibliothèques sont dynamiques, mais la liaison est statique.

encore une fois, tu te trompes...

Tes 2 premiers paragraphes montrent que tu n'as pas compris...

Les bibliothèques ne sont pas "dynamiques et la liasion statique".

SI ON FAIT l'EDITION DE LIEN DU PROGRAMME AVEC DES LIBRAIRIES STATIQUES IL N'Y PAS BESOIN DE RUNTIME LIBRARIES., car le code de la biblothèque est DANS le binaire

Si par contre on fait l'édition de lien avec des librairies dynamiques, le programme, pour rouler, a besoin de ces librairies runtime, puisqu'il contient un "jump" (ce jump est bien sûr statique dans le code, mais l'adresse qu'il contient est l'adresse du fichier existant, donc si tu changes de plateforme tu changes de fichier).



C'est si diffcile à comprendre ???????????


Note bien que je ne parle pas de "problèmes de liaisons de bibliothèques dynamiques". Je parle du CODE de ces librairies (à cause du jump, c'est ce code qui est éxécuté, et donc, suivant le système ET la bibliothèqque, on peut avoir des réponses différentes). La liaison, c'est un jump, on s'en fiche un peu. Comment la fonction est codée, où la biblothèque est placée sur le disque, combien on a de mémoire, etc etc tout cela intervient alors (on a plusieurs programmes tournant en //).




Les références et incertitudes de tes références sont simplement parce que c'est écrit par quelqu'un comme toi...

[dfg]

encore une fois, tu te trompes...

Tes 2 premiers paragraphes montrent que tu n'as pas compris...

Les bibliothèques ne sont pas "dynamiques et la liasion statique".

SI ON FAIT l'EDITION DE LIEN DU PROGRAMME AVEC DES LIBRAIRIES STATIQUES IL N'Y PAS BESOIN DE RUNTIME LIBRARIES., car le code de la biblothèque est DANS le binaire

Si par contre on fait l'édition de lien avec des librairies dynamiques, le programme, pour rouler, a besoin de ces librairies runtime, puisqu'il contient un "jump" (ce jump est bien sûr statique dans le code, mais l'adresse qu'il contient est l'adresse du fichier existant, donc si tu changes de plateforme tu changes de fichier).

Excuse-moi si je me trompe, mais j'ai l'impression que tu confonds shared library et runtime library. Sinon pourrais-tu expliquer ce que tu entends par runtime library ?

Cette page de la msdn présente les C Run-Time Libraries de microsoft :
http://msdn.microsoft.com/en-us/libr...yh(VS.80).aspx

Dans la 1ère ligne du tableau, on voit que la runtime library libcmt.lib n'a pas de dll associée ; elle est liée statiquement. Donc on est bien en présence d'un cas de liaison statique où on a besoin d'une runtime library.

Les références et incertitudes de tes références sont simplement parce que c'est écrit par quelqu'un comme toi...

Comment définis-tu les gens "comme moi" ? Personnellement je n'irais jamais écrire un article sur quelque chose que je ne connais pas sur le bout des doigts !

[souviron34]

D'après le pointeur que tu donnes, ils ont eux-même des problèmes à donner une définition claire

Dans la 1ère ligne du tableau, on voit que la runtime library libcmt.lib n'a pas de dll associée ; elle est liée statiquement. Donc on est bien en présence d'un cas de liaison statique où on a besoin d'une runtime library.

NON. Relis attentivement : cela dit qu'elle est liée statiquement POUR UNE DLL, pas pour un éxécutable.

Personnellement je n'irais jamais écrire un article sur quelque chose que je ne connais pas sur le bout des doigts !

Alors tu es très naif....

Et Wikipédia est un excellent exemple de ramasis d'approximations et de fausses informations, de concepts non maîtrisés, etc etc..

[dfg]

NON. Relis attentivement : cela dit qu'elle est liée statiquement POUR UNE DLL, pas pour un éxécutable.

Où est-ce que tu vois ça ? Je ne vois pas du tout. Pourrais-tu citer le passage s'il te plaît ?

Alors tu es très naif....

Et Wikipédia est un excellent exemple de ramasis d'approximations et de fausses informations, de concepts non maîtrisés, etc etc..

J'ai l'air si naïf que ça ?