PureBasic

Oui , traiter du bytecode est extrement rapide pour un interpreteur, ayant utilisé pas mal d'entre eux , lua, javascript avec duktpae, etc...
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 )
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.



Clang/LLVM compile du C/C++ et d'autre langage... il passe par un bytecode nommé IR ( intermediate representation )
exemple cette fonction C :



deviens en IR :



Il y a des outils avec LLVM/clang qui convertit cet IR en executable pour X86,X64,ARM,etc...
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






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 ?
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...
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.
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

Ce n'est pas tout à fait vrai, FASM comme tout assembleur peut créer des fichiers objet (aucun rapport avec la POO) parfaitement compatibles avec n'importe quel OS puisque simplement en langage machine "pur" ; ces fichiers peuvent ensuite être utilisés pour créer un exe ou un elf grâce à l'édition de liens, ou un code de boot, ou autre chose.

Les OS fonctionnent d'une façon très différente en ce qui concerne la nature des fichiers "exécutables" et le chargement en mémoire. Par exemple, sous Windows et Linux, tout programme chargé croit qu'il est seul au monde et fonctionne en mode "absolu" : c'est à dire que le programme sait où se situent l'OS, ses labels et ses variables parce que chaque adresse du programme va être relocalisée (recalculée) lors du chargement. Toute adresse est définie de façon absolue dans l'étendue possible de la RAM, de 0 à x bits.

C'est aussi pour cela qu'il y a eu des problèmes chaque fois que les ordinateurs ont évolué, car quand on passe de 8 bits à 16, 32 ou 64, c'est tout l'environnement "naturel" du programme qui change ! Sur AmigaOS, il n'y a qu'une seule valeur absolue, tout le système est basée sur des adresses relatives. C'est hautement efficient en terme de passage de valeurs puisqu'on ne passe que des pointeurs, et il n'y a jamais de copies de structures. Le problème vient du risque d'écrasement de zones mémoires non protégées. Mais je m'égare.

Tout ça simplement pour dire qu'il est parfaitement possible d'intégrer un code à un EXE, si l'on sait soit travailler en relatif et se passer de variables, soit modifier les entêtes de l'EXE. C'est ce que font certains virus ou certains packers.

Pour ce qui est des différents "MOV", ils viennent du fait que FASM est un assembleur un peu amélioré et qu'il n'utilise pas un assembleur "pur" : il facilite la vie du programmeur avec une syntaxe un peu plus simple et du coup, le code résultant n'est pas toujours le même que celui que l'on a prévu. Mais en programmant en assembleur "officiel", un MOV reste un MOV, et le restera sauf si le chargeur ou un "optimisateur" passe par là

oui, je ne connais l'asm qu'a travers les debuggers
et pour avoir "debuggé" quelques prg, je peut effectivement t'affirmer, que ceux ci
se logent toujours au meme endroits (sous windows) et que leur adresses sont bien relative
a leur "debut" ... du coups les patchs de "corrections" de bug , en "pokan" la bonne valeur
sur le bon octet (en ayant recherché la bonne séquence préalablement dans le fichier Exe)
remplaçant un JE par un simple JNE , ça marchait tres bien
et que chaque opérandes, opcode, a une certaine identité Hexadecimal, qui reste constante .
c'est tres visible si tu utilise un debugger...(W32DASM ;OllyDbg ; et le meilleur "SoftICE" et son Ctrl+D legendaire )

il me semble me souvenir que quelqu'un ici sur ce forum a posté un code
qui permet "d'injecter" un code dans un exe pour en faire siens..
mais je ne me souviens plus qui , ni quand ... je ferai une recherche a l'occase ..

le Soldat inconnu il me semble avait aussi posté a ce sujet (ça concerne de l'injection de code dans un executable )

[reedit]
trouvé , c'est Mytic qui avait utilisé ce principe d'injecter son code dans un executable
pour en faire un executable (un compilateur maison )
ici :
viewtopic.php?f=8&t=7201&hilit=injection

par contre, je ne sais pas s'il avait donné son code au final ....




@Grom , tu as détourné mes phrases de leur contexte

lorsque je dis "c'est plus simple qu'une traduction d'un langage X vers un langage Y"
je parlais de ma methode (interpreter les lignes une a une pour faire une execution a la volée (bouger une tortue dans mon cas) )

lorsque je dis "car je n'ai qu'a surveiller une seule syntaxe ... "
je parlais bien sur de ma methode , la seule syntxe a surveiller, c'est mon langage maison (le PureGolo en l'occurence )
avant execution de celui-ci

toi en réalité tu as 2 verif de syntaxe a faire
celle du langage maison pour en faire un Bytecode
celle de ton byte code pour en faire un langage connu (le purebasic ou un autre )

je crois aussi qu'on utilise pas les memes termes
lorsque tu dis :


si j'ai bien compris l'IR est une sorte de byte code , donc il n'a pas a etre "interprété"
tout au plus il doit etre "Traduit"

rappel un interpreteur c'est un prg qui "interprete" les mots d'un langage pour effectuer une action !

les anciens Basic etaient "interpretés" , chaque commande faisaient une action
Print "Toto" , etait interprété par l'interpreteur pour ecrire a l'ecran le mot "toto"

donc ton bytecode , n'as pas a etre interprété , c'est pas lui le langage
c'est juste un code intermédiaire qui a pour vocation a etre traduit
et c'est le résultat de cette traduction qui sera interprété ou compilé ..

et donc, je replace le "bytecode" a sa juste place , c'est juste une convention d'ecriture
mais je me demande encore si ça a un réélle utilité

c'est comme si tu disais , que pour parler a un américain , il me faut d'abord traduire en chinois ce que je dis en français
et que quelqu'un (un chinois) va traduire le chinois en américain ...

je me demande juste pourquoi ne pas traduire directement en Anglais ce que je dis en français ...
bref , ton histoire de Bytecode, me fais penser au sketch de Fernand Reynaud , "le 22 a Asnieres"
http://www.ina.fr/video/I06268515

si tu me reponds que c'est juste pour etre dans une norme, ok, je comprends
mais sinon , franchement, je vois pas l'interet ... mais tu sais que je suis bouché

@Djes


Oui mais ce n'est pas le sujet, et cela dépends aussi du compilateur, un fichier objet est dès fois pas compatible d'un même compilateur d'une version a l'autre, quand à l'utilisé d'un OS à un autre, cela dépends du compilateur.



Oui, je l'ai déjà fait, c'est du bricolage, mais on ne balance pas du code ASM brut dans un exe "exesquelette" , c'est plus compliqué que cela.



La dessus je ne suis pas d'accord, pour toi un MOV reste un MOV , dans ton code on est d'accord, mais le processeur lui non, en fonctions de différente opérande
pour le MOV , il peut prendre plusieurs valeur , prend cet exemple qui démontre ce que je te dis :



fait un exe et désassemble le.
le premier MOV vaut 0xB8, le second 0x89, conforment au datasheet d'un x86 : http://ref.x86asm.net/coder32.html#x66


Le code ci dessus est exactement le même dans l'exe final, rien ne change.

ps: j'ai fait un compilateur ASM pour PIC , donc je connais bien cette partie


@Zorro



C'est la ton incompréhension , au contraire, un bytecode EST la représentation de ton langage en instruction simple et élémentaire que tu as choisi ( ADD MUL PUSH POP , etc... ) tu peut à partir de lui, soit le compilé directement ( plus dur car il faut bien connaitre le format cible PE/ELF,etc... ) pour faire un exe, soit l'interprété dans une machine virtuelle , soit le traduire ( comme le fait PB ) dans un autre langage.

Un byte code , c'est juste en PB : list ByteCode.a() , c'est quand même mieux et plus rapide de traité un bytecode préalablement vérifié
que de parser des strings a la volée...



Oui, mais tes mots sont transformé en byte code, c'est pas une question de norme , mais de bon sens.




Non, encore une fois , tu n'as rien compris. en gros :

- Tu vide ton code source des commentaires
- Tu sépares et sauvegarde chaque mot , chaque mot sauvegardé contient sa ligne dans le code, son fichier
ce qui donne en PB :



- je passe le traitement preproc, include, macro, etc...
A la fin , tu as donc une liste de mots ( Token ) avec dedans pour chacun un type inconnu

- Tu identifie tout les mots ( c'est une variable ? une structure ? un opérateur ? un nombre ? un string ? etc ? )
- Tout dois être identifié parfaitement
- si tu as un type inconnu a la fin , tu génère une erreur propre , vu que tu as sauvegardé la ligne & le fichier dans le mot

- dans le cas d'une variable a déclaré, tu tombe sur un mot qui représente une variable "Toto.l"
- tu regardes si la variable est déjà déclarée ( dans une simple table des variable , avec une map par ex ) ( je ne parle pas de la portée , un simple arbre suffit à géré cela, la racine à la portée globale , les branches les portée locale, chaque branche possède ses tables de variables )
- si elle est déjà déclaré , rebelote , tu génère une erreur.
- sinon tu l'ajoute a la table des variable en fonction du scope
- pareil pour tout le reste

Ensuite si ta liste ne contient plus de token non identifié , tu passe à la suite, il faut généré le byte code a partir de la liste des tokens
en prenant en compte les subtilités
par exemple : if A = 5 ou A = 5 le '=' n'aura pas le même opcode, car il ne fait pas la même chose , d'un coté un test, de l'autre une affectation

une fois que ton byte code est généré , il faut faire une analyse sémantique de ton byte code , voir si il est bien formé
par exemple disont que le code suivant génère une erreur :

en PB :

if A === 5

avec un opcode maison :

OPERATOR_IF
VARIABLE
OPERATOR_EQUAL
OPERATOR_EQUAL
OPERATOR_EQUAL
VALUE


Arrivé au premier OPERATOR_EQUAL , ton "compilateur" s'attend pour la prochaine instruction a avoir ( selon ton langage ) soit une valeur , une fonction , mais pas un autre operateur.

Les régles de sémantique sont quand même plus simple a traité comme cela qu'avec des strings a la volée !
en PB ca donnerais ce genre de chose :



c'est quand même plus propre est moins brainfuck qu'une série de Stringfield() Ucase() Lcase() Mid()....


Non, c'est pas constant !

http://ref.x86asm.net/coder32.html#x66

MOV, AND et d'autres change en fonctions des opérandes , c'est ce que j'expliquais à Djes.

Je pense qu'on s'est mal compris. C'est tout à fait normal que selon les opérandes, le code soit différent, surtout pour les instructions «historiques», peu nombreuses, qui devaient tenir sur un octet (notamment celles qui utilisent les registres). Mais lors du désassemblage d'un exe, si tu avais utilisé un assembleur respectueux (ou directement du langage machine), tu récupéreras le mov que tu avais mis, sans surprise. Je pensais que tu parlais du fait que parfois, le code résultant de l'assemblage par fasm est différent, car celui-ci effectue de petites optimisations et n'utilise pas une syntaxe officielle.

Pour le reste, c'est très intéressant le bytecode, moi je me régale de ce genre de conversation, même si... C'est déjà du passé ! Il est temps de penser en quantique, Al, etc. Et l'OO fait partie des évolutions qu'il est temps d'intégrer, pour mieux les dépasser !

ha vous entendre , on pourrai croire, que sans bytecode, point d’interpréteur
je suis désolé de vous le redire , je l'ai fait !



ben c'est un point de vue ... mais il n'empeche qu'on peut faire sans ... je l'ai fait !



ceux a quoi tu me reponds :


1er Verif :



2em Verif



bon ben c'est ce que je disais .



oui en absolu , mais j'ai bien parlé d'utiliser un debuggeur ...
et pour un debuggeur ton Mov , ton JE (JZ) ou ton JNE (JNZ) apparaitra bien toujour sous ce nom
et pour les saut, la valeur reste constante !!
de plus un debuggeur affiche les 2 , le nom et sa valeur Hexa ... bref ...



personne ne dis que c'est simple , mais Mytic l'a fait !
de memoire, il utilise une icone pour marquer l'emplacement de l'injection de son code
ensuite, il doit probablement modifier le PE pour sauter au debut de son code

le fait est, qu'il avait réussi a creer son petit langage, qui pondait des Executables en utilisant ce principe

je crois meme que l'exe final contenant en fait son interpreteur complet
ce qui fait qu'au lancement, l'exe lançais en interne son interpreteur, qui lui executait le code

dommage que Mytic ne passe plus par ici , il devait expliquer en detail sa methode, mais cela n'a jamais abouti ...

c'est le principe de base de "l'injection" :
inserer un code dans un autre, pour le faire executer a sa place
il y a quelques code a ce sujet dans le forum anglais ...

ça reste de la bidouille , mais ça fonctionne , et cela a deja été fait !

le compilateur du pauvre en quelque sorte

Petit résumé, je n'ai pas la prétention de faire un compilateur et encore moins de réinventé la roue. Pb fonctionne bien et je ne veux en aucun remplacer son code.

La seule tache est de classifier le code avec les mots clés Class, EndClass, Static,Abstract en extraire les membres avec Private, Public, Static ainsi que les méthodes avec Method, EndMethod etc.

Ainsi donc le code est séparé en plusieurs parties une partie par class, et le code en dehors de la class (qui ne devrais normalement être composé que de quelques lignes).

A chaque lecture de ligne si aucun mot clé n'est trouvé le code est pris en l'état et non vérifié.

Le plus difficile reste à faire il s'agis de l'appel de méthodes en cascade

Exemple :



Je signale également que le code devra être écrit avec rigueur et n'autorisera pas beaucoup de fantaisie.

J'ai jamais dit le contraire, moi aussi je l'ai fait, mais j'ai fait de la merde.



Relis bien, il n'y a qu'une seule analyse de syntaxe, l'autre est une analyse sémantique, c'est pas la même chose. joue pas sur les mots...



Pas de bol, JE est variable en opcode x86 , 2 opcode possible , lance ollydbg et trace un programme !



La liste des opcodes X86 : http://ref.x86asm.net/coder32.html



Moi aussi je l'ai fait, mais sous linux



Exactement , le lien : http://www.purebasic.fr/french/viewtopic.php?f=14&t=9132&view=next


Après si tu veut resté dans la médiocrité , libre à toi... , moi je te donne une méthode éprouvée qui marche.

Et pour rester dans l’ambiance je lance un pavé dans la mare et annonce que j'écris mon pré compilateur en Java

Et bonne année à tous même si ce que je dis ressemble à un poisson d'avril (mais n'en est pas un)

et du coup , tu t'es dit, "java l'dire a tout le monde"

Java cette idée Zorro