- La première méthode, celle que j'avais imaginé en premier, il y a assez longtemps, c'était de construire une arborescence du code très complète, contenant les namespaces, les classes ainsi que leurs membres (y compris les variables locales privées, publiques, protégées), puis dans une seconde passe, d'analyser le code en lui-même, et comme l'arborescence a été construite, on peut facilement détecter les appels de fonctions invalides, les types non définis, etc...
- La deuxième méthode est similaire, mais on analyse aussi le code dans la première passe, en vérifiant au maximum la validité des appels de fonctions et la validité des types, sachant que l'arborescence n'est pas totalement construite, et dans une seconde passe, qui peut être effectuée durant la compilation (ce qui n'est pas possible, puisqu'il faudra aussi optimiser), on s'occupe de la résolution de type et de surcharge.
J'aimerais savoir ce que vous pensez de ces deux méthodes, laquelle est la meilleure, et si vous en avez une encore meilleure à proposer
Voilà pour la première question
Ensuite, pour avoir un langage correct, il faut évidemment une bibliothèque standard, donc le compilateur devra pouvoir créer des librairies, ce n'est pas réellement un problème, même si je ne sais pas encore comment gérer tout ça (c à d comment stocker les infos de type, et tout...). Mais la librairie standard devra posséder des fonctions d'accès à la mémoire, ce qui ne serait pas possible en compilant en compilant en basic. J'ai donc pensé à créer un assembleur 68k spécial pour la compilation objet, mais en y réfléchissant bien, cela se révélait quasi-impossible, puisque la gestion des l'héritage, des surcharges, etc (sans parler du stockage des informations de types) est quasi-impossible en assembleur. A ce moment là, j'ai pensé à un pseudo assembleur, qui gererait tout ce qui était nécéssaire tel que l'appel de fonctions dans les classes ou, la sécurité des types, qui se transformerait très facilement en n'importe quel assembleur (m68k, x86), ce qui pourrait être utilisé pour la compilation basic et même pour compiler d'autres langages. Le pseudo assembleur ressemblerait quelque peu à ça:
.namespace System .class Memory, public, fixed .function Peek(long addr), byte, shared, public, overload .local result, byte mov result,[addr] ret result .endfunction .function Peek(long addr), short, shared, public, overload .local result, short mov result,[addr] ret result .endfunction .function Peek(long addr), long, shared, public, overload .local result, long mov result,[addr] ret result .endfunction .procedure Copy(long dest, long src, long length), shared, public .local jumptable, long .local rc_addr, long mov jumptable,[$C8] mov rc_addr,[jumptable+($264*4)] push length push src push dest jsr [rc_addr] .endprocedure .endclass .endnamespaceIl va sans dire que la conversion en assembleur natif serait très optimisée...
C'est peut-être un peu ambitieux comme projet (
), mais qu'en pensez vous ?
Et puis il faut que tu indiques la taille de tes opérandes quelque part. La syntaxe Intel le fait dans les opérandes, sur 68k, ça se fait normalement à la fin des codes d'instructions.
) Non, je rigole (encore que, ça doit être relativement faisable ^^), mais attends-toi qd même à ce que le code généré soit GROS si tu stockes un binaire. Et si tu veux implémenter toutes les capacités de réflexion, ça peut aider d'avoir un bytecode à portée de main
Mais je ne sais pas programmer en C#, et le langage est beaucoup plus complexe que le VB (quoique parfois...)
) b) Mettre des suffixes de taille c'était plutôt barbare, et qu'avec les déclarations de variables locales, ça devenait quasi inutile (et en plus ça fairait de la redondance, et le code deviendrait quasi-inoptimisable)
Je pense pas, surtout si tu as fait du C++.
Il suffit d'afficher l'onglet assembleur, et tu verras... (par contre mieux vaux ne pas le laisser ouvert si tu ne t'en sert pas parce que ça fait bugger les onglets au bout de qq débogages 
)
Mais si on s'en sert avec modération, c plus efficace de mettre un attribut que de rajouter du code...
Tout ça se fait en statique, tant que tu n'as pas de types Variant.
On le changera jamais le Kevin ^^
On le changera jamais le Kevin ^^