c'est hyper performant.
non , justement, tu "traduit" X vers Y pour faire du Z ( ce que fait PB(X) vers de l'asm(Y) pour faire un exe (Z) ), les erreurs de syntaxe sont traité en X des lors que du traite les mots individuellement ( les tokens )c'est plus simple qu'une traduction d'un langage X vers un langage Y
et les erreurs de sémantique sont traité en Y , par exemple trois opcode d'operateur se suivent... : " = = = ", une fois que les erreurs de syntaxe et de sémantique
sont traité en Y, le bytecode est bon, Z sera bon aussi , rien a checké pour Z ( le langage cible ) , en admettant que le code qui traduit Y vers Z soit sans bug...
là le but est de faire du code PB-OO(X) vers ByteCode(Y), pour produire un code PB valide (Z), mais en Z tu fait ce que tu veut, si le bytecode est béton, tu produit ce qu'il te chante, un interpréteur, un compilateur d'exe...
ici aussi. le langage cible, le byte code est traité par une machine a état ( l'histoire des 3 tokens operator qui se suivent ) , une fois qu'il est validé , il n'y a plus de check a faire sur le byte code.car je n'ai qu'a surveiller une seule syntaxe ...
Clang/LLVM compile du C/C++ et d'autre langage... il passe par un bytecode nommé IR ( intermediate representation )bref, je ne pense pas que le passage par le bytecode, soit obligatoire .. c'est juste une methode (une bonne methode ?)
exemple cette fonction C :
deviens en IR :int mul_add(int x, int y, int z) {
return x * y + z;
}
Il y a des outils avec LLVM/clang qui convertit cet IR en executable pour X86,X64,ARM,etc...define i32 @mul_add(i32 %x, i32 %y, i32 %z) {
entry:
%tmp = mul i32 %x, %y
%tmp2 = add i32 %tmp, %z
ret i32 %tmp2
}
Donc, c'est la meilleur méthode qui existe pour être portable, n'importe qui est libre de faire un interpréteur d'IR, l'IR généré est d'office bon.
ha... ca existe déjà : https://github.com/graalvm/sulong
With Sulong you can execute C/C++, Fortran, and other programming languages that can be transformed to LLVM bitcode...
Met toi a la page papy, l'IR est justement pour évité cela, qui est capable ici de créer un compilateur qui transforme réellement un code en code executable ?pour qu'un compilateur soit capable de créer un exécutable , a mon avis, il faut connaitre
comment un exécutable est créé
des compilateurs qui sorte des exe , y en a pas des masse ( gcc, clang, visual, fasm, nasm, et une poignée d'autre... ) , PureBasic ne compte pas, c'est Fasm qui fait l'exe final. même si tu sait le faire, tu ne sera jamais aussi performant que les compilo qui existent, surtout sur l'optimisation du code machine. même Fred n'a certainement pas les compétence pour le faire, d'ou le choix de fasm car il maitrise son sujet, l'asm. Fred ne c'est pas preocuppé de l'entete d'un PE ou l'entête d'un ELF quand il a fait PB...
Fasm le fait très bien pour lui !
Ca marche pas comme ca, un PE y a des sections, en fonction d'ou ce trouve tel code , ton code ASM n'est plus même certaine valeur change, etc...l'architecture d'un fichier EXE ... entête ...etc ...
pour pouvoir y insérer notre code dedans ... et ainsi avoir un exécutable de notre code
une sorte de squelette de *.EXE dans lequel on insere notre code Asm et roule ma poule
un code ASM brut non compilé n'est pas un langage machine , par exemple MOV en asm peut avoir plusieurs valeur d'opcode primaire
il ne suffit pas de glisser un code ASM dans un exosquelette d'exécutable, si tu réussi, dans ce cas, tu résouts le problème de portabilité entre linux & windows
suffit de changé de squelette... t'en raconte des connerie... hahaha
Donc, purebasic utilise un langage intermédiaire préétablie , l'ASM.bref, je ne pense pas que le passage par le bytecode, soit obligatoire ..
Pour conclure , il y a la méthode ISO-1664, la tienne , et celle que je te parle qui est utilisé par LLVM Clang Javascript-Duktape Javascript-V8 Lua gdscript AngelScript PureBasic, DarkBasic Pro... et une floppé de tools qui existe
Pour DBPro , regarde le source code ici : https://github.com/LeeBamberTGC/Dark-Ba ... SMWriter.h
tout le bytecode intermédiaire est énuméré à la ligne 18 jusqu'à la ligne 386