En gros, avec un compilateur qui va bien, on doit pouvoir se ramener avec un programme écrit en C au même niveau de performance/taille d'exécutable que ce qu'on arrive à faire avec Lisaac?
Probablement pas, parce qu'il est plus facile de descendre que de remonter.
Pour ceux que cette explication ne satisfait pas, je vais essayer de faire mieux mais c'est pas gagné. Quand on écrit un programme dans un langage de haut niveau, les mots et les constructions du langage ont du sens qu'il n'est pas toujours possible de traduire dans le langage de bas niveau. Par exemple, dire qu'une classe hérite d'une autre a un sens si on se place à un certain niveau, mais le code en assembleur qui résulte de la compilation ne contient pas cette information.
Pour retrouver l'information à partir du code de bas niveau, il faut être capable de l'analyser pour "remonter" dans les niveaux. Pour certaines choses, c'est possible, par exemple on peut assez facilement à partir de l'assembleur retrouver des structures de boucle. Mais est-ce toujours possible ?
- Le programme compilé ne contient pas forcément toute l'information. Par exemple la hiérarchie d'héritage des classes ne sera probablement pas représentée en entier ou correctement.
- L'analyse de programme est difficile. Tellement difficile que certaines choses sont impossibles. On ne peut pas, par exemple, faire un programme qui peut analyser n'importe quel programme et dire s'il s'arrête ou s'il boucle indéfiniment. D'un autre côté, je doute qu'il soit possible de faire un langage de haut niveau qui permet d'exprimer qu'un programme boucle sans que le code résultant ne puisse être analysé pour le déduire.
- L'analyse de programme est difficile (bis). Un programme, c'est un graphe assez énorme, et pour "remonter", il faut être capable de découvrir des structures de haut niveau dans ce graphe, ce qui n'est pas évident. Pour prendre un exemple simplifié, prend une feuille de papier, et interroge des gens dans la rue. Pour chaque personne, inscris un rond avec leur nom, et puis si deux personnes se connaissent, relie leurs ronds par un trait. Une fois que c'est fini, essaye de retrouver les familles. Une famille, c'est une structure de haut niveau dans ton graphe des "connaissances", mais c'est incroyablement difficile à retrouver si on n'a pas l'information.
[^] # Re: Inutile
Posté par Yusei (Mastodon) . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 6.
Probablement pas, parce qu'il est plus facile de descendre que de remonter.
Pour ceux que cette explication ne satisfait pas, je vais essayer de faire mieux mais c'est pas gagné. Quand on écrit un programme dans un langage de haut niveau, les mots et les constructions du langage ont du sens qu'il n'est pas toujours possible de traduire dans le langage de bas niveau. Par exemple, dire qu'une classe hérite d'une autre a un sens si on se place à un certain niveau, mais le code en assembleur qui résulte de la compilation ne contient pas cette information.
Pour retrouver l'information à partir du code de bas niveau, il faut être capable de l'analyser pour "remonter" dans les niveaux. Pour certaines choses, c'est possible, par exemple on peut assez facilement à partir de l'assembleur retrouver des structures de boucle. Mais est-ce toujours possible ?
- Le programme compilé ne contient pas forcément toute l'information. Par exemple la hiérarchie d'héritage des classes ne sera probablement pas représentée en entier ou correctement.
- L'analyse de programme est difficile. Tellement difficile que certaines choses sont impossibles. On ne peut pas, par exemple, faire un programme qui peut analyser n'importe quel programme et dire s'il s'arrête ou s'il boucle indéfiniment. D'un autre côté, je doute qu'il soit possible de faire un langage de haut niveau qui permet d'exprimer qu'un programme boucle sans que le code résultant ne puisse être analysé pour le déduire.
- L'analyse de programme est difficile (bis). Un programme, c'est un graphe assez énorme, et pour "remonter", il faut être capable de découvrir des structures de haut niveau dans ce graphe, ce qui n'est pas évident. Pour prendre un exemple simplifié, prend une feuille de papier, et interroge des gens dans la rue. Pour chaque personne, inscris un rond avec leur nom, et puis si deux personnes se connaissent, relie leurs ronds par un trait. Une fois que c'est fini, essaye de retrouver les familles. Une famille, c'est une structure de haut niveau dans ton graphe des "connaissances", mais c'est incroyablement difficile à retrouver si on n'a pas l'information.