KONKYO (ASM COMPILER, DECOMPILER, DEBUGGER, MACHINE VIRTUELLE)
cs_Xs
Messages postés
368
Date d'inscription
mercredi 14 novembre 2001
Statut
Membre
Dernière intervention
1 septembre 2008
-
15 avril 2005 à 12:13
cs_hakim0 Messages postés 123 Date d'inscription mercredi 27 août 2003 Statut Membre Dernière intervention 12 août 2008 - 22 avril 2006 à 02:22
cs_hakim0 Messages postés 123 Date d'inscription mercredi 27 août 2003 Statut Membre Dernière intervention 12 août 2008 - 22 avril 2006 à 02:22
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/30755-konkyo-asm-compiler-decompiler-debugger-machine-virtuelle
https://codes-sources.commentcamarche.net/source/30755-konkyo-asm-compiler-decompiler-debugger-machine-virtuelle
22 avril 2006 à 02:22
Merci
21 avril 2006 à 22:44
class piko;
class numb{
piko *p;
};
class piko{
numb *p
};
21 avril 2006 à 16:28
********
class numb{
piko *p;
};
class piko{
numb *p
};
********
ca march pas??? besoin d'aide.
20 avril 2006 à 23:04
20 avril 2006 à 12:00
20 avril 2006 à 10:23
20 avril 2006 à 02:06
j'ai une question: comment pe modifier la signateur d'un programm? avec visual c++,mode binair??
25 mars 2006 à 13:05
ensuite il faudra que je relise tout les posts de cette page et faire un resumer de ce que je dois prendre en compte pour les autres modifs futures
bon week-end a tous
25 mars 2006 à 02:06
bon sinon pour le code a factoriser, bah en fait les premieres conclusion sont :
le code qui me semble etre le seul factorisable est le code ou se trouvent les fonctions equivalente aux opcodes (fichier parse_opcodes.c dans le projet libkvm)
le code factorisable est le code de verification de l'etat de la pile et de l'etat du tas (verification des stack overflow et de l'adressage), j'en ai tiré 3 conclusions, les voici :
1ere conclusion : je peux factoriser du code dans des fonctions, ce qui ne me fera ecomiser que 4 lignes de codes par fonction en moyenne (et encore, dans peu de fonctions), c'est pas terrible et je veux pas faire trop d'appel (les empilement/dépilement d'appels de fonction prennent du temps)
2eme conclusion : je peux remplacer des bouts de code plus ou moins similaires par des #define, mais ca implique d'avoir des BEGIN_TRUC et END_TRUC... pas terrible, de plus ca fera des #defines mega degeulasse, et les #define c'est pas terrible pour débugger ni pour comprendre le code
3eme conclusion : j'oublie les 2 premieres conclusion et je laise le code tel quel.
enfin biensure je ne le laisse pas tel quel, le préprocesseur et la machine virtuelle compile en 0 errors 0 warnings, toutes les fonctions deprecated on été remplacées par les nouvelles fonctions secure, j'ai corrigé le bug de la table d'adressage qui etait pas reinitialiser au chargement d'un autre script.
pour le moment c'est a peut pres tout, mais je continue a déwarniser les autres projets et j'espere pouvoir vous fournir un truc correct bientot.
je vais aussi essayer de faire tourner un truc qui dechire sur mon PDA pour faire des tests de perfs... je sais pas encore quoi mais je compte sur vous pour me donner des idées ^^
merci a vous de suivre le projet, et a très bientot pour la mise a jour de KonKyo en Visual Studio 2005
25 mars 2006 à 00:35
Je peux pas garantir de delai car je lutte un peu, a cause des fonction C standard passées en deprecated, j'ai 80 warnings et rien que sur le préprocesseur :S
donc voila, je vous tiendrais au courrant quand tout sera fini, je posterais une mise a jour avec le nouveau code
23 janv. 2006 à 12:56
23 janv. 2006 à 10:19
pour les elements compilé, c'est jouable, il faut juste que tu me dise tes preferences en terme de compilation/linkage (Dev C++/VS6/VS7/VS2005, linkage static/dynamic, etc...)
sinon tu doit pouvoir trouver des trucs deja compiler a l'adresse ci-dessous, mais je ne sais pas si ca te conviendra
http://konkyo.free.fr/tool_pack.zip
(doc : http://konkyo.free.fr/konkyo.pdf)
20 janv. 2006 à 18:10
t'as quoi comme compilo ?
(PS : Seb je n'ai pas oublié mais bon, les etudes sont ce qu'elles sont :s )
20 janv. 2006 à 13:44
Je sais que ma question peut paraître triviale au vu de tous les commentaires faits précédemment, mais serait il possible d'avoir les différents éléments compilés ...
MERCI d'avance
11 juil. 2005 à 20:22
heu... je ne sais pas comment on le fait en assembleur, mais il n'y a pas d'instruction pour le faire. n'oublie pas que la VM est ecrite en C, et que c'est la VM qui execute le bytecode, donc lorsque la VM rencontre cette opcode, elle fait tout simplement un cast, donc en gros
KonKyo :
mov dreg[0], freg[0]
=
C :
dreg[0] = (int)freg[0];
"ya juste que je savais pas que tu filais une adresse a la fonction"
hehe, desoler je voulais pas te prendre pour un boulet, t'inquiete :) mais tu as dit avoir lu la doc, et la doc explicit clairement le prototype de la fonction que je te rappel ci-dessous :
int kvm_set_dregs(int dreg_number, int *dreg, t_kvm *kvm);
le deuxieme parametre est bien un pointeur, c'est celui qui recoit l'adresse de la zone memoire de travail pour la VM.
"en fait c'est un peu un "manque " (si j'ose dire) de KonKyo qi ne comprend pas un truc genre dregs[dregs[IDX]], c'est ca? et du coup ya get pour compenser..."
c'est exactement ca, j'aurais pas dit mieux :) helas je suis obliger d'admettre aussi les faiblesses de KonKyo, je n'ai pas le droit de duper les gents. le problem est au niveau du bytecode, il est fixer, et quand un parametre est de type dreg, l'argument du parametre (je me comprend ^^) ne peux etre qu'une valeur numerique ecrite en dure, je ne peux pas mettre en argument un autre dreg qui aurait lui-meme un argument de valeur numerique (IDX en l'occurence dans l'exemple que tu as mis) mon bytecode n'as pas ete penser pour pouvoir faire ce genre de chose helas, mais ca aurait effectivement ete l'ideal.
et donc comme tu dit, set et get sont la pour "boucher les trous" :P
"quels sont les avantages dee KonKyo par rapport a une dll écrite en C et donc plus abordable pour un débutant?"
konkyo est simple a mettre en place, ce qui inclue l'ecriture de code, c'est comme programmer un proce microchip, tu as tres peux de mode d'adressage et une trentaine d'instruction, c'est on ne peux plus simple. la il n'y a pas de notions de mode d'adressage ni de notions de bank ni autre trucs complex de l'assembleur qui gene toujours les debutant.
ceci dit, un autre avantage bah c'est tout simplement l'avantage qu'offre les scripts, c'est que par exemple tu peux modifier un script a la derniere minute un peux a l'arache et relancer le bignou et c'est partit. j'admet ceci dit que pour faire ca, il faudrait integrer la compilation du script dans la VM avant l'execution... chose que je n'ai pas faite ^^ (ca c'est vraiment vu ? :P)
enfin voila, je sais pas trop comment le dire parcequ'il y a plein de choses a dire, mais en gros ca donne tout les avantages que peux offrir le scripting, sauf que c'est vrai que l'asm c'est un peux moisit pour tapper du script, car aussi le script est censer etre une chose facile que n'importe qui doit pouvoir faire, et j'avoue que j'ai du mal a imaginer ma grand-mere tapper du code asm :S
sinon pour utilisation dans un prog opengl, je n'en ai aucune idee la tout de suite, mais dans un projet de 3D il y a toujours de petite tache a realiser et qu'on peut faire faire par un script :P par exemple un enemi calcul sa distance par rapport a ta position, et si elle est trop elever, il s'arrete de tirer pour ne pas avoir l'air d'un gros naze ^^ ce genre de petites choses :P
7 juil. 2005 à 21:42
'bytecode specialement concu pour la machine virtuelle de KonKyo' -> oui oui je sais ce qu'est un bytecode... la question était: comment fait on en ASM ? ou alors la conversion, c'est le compilo C que tu as utilisé pour compiler ta lib qui la fait...
pour PSP/GBA : tu as l'air de penser que je tiens absolument a ce que ca marche sous ces plate-formes. pas du tout mdr, c'était une simple curiosité ^^ en fait je n'ai aucune console (heu... une game boy ca compte ? ^^ )
pour les tableaux: oué bon ca va hein, chuis pas un pro avec les pointeurs mais ya des limites qd meme mdr, ya juste que je savais pas que tu filais une adresse a la fonction
pour get et set: j'ai compris, merci. en fait c'est un peu un "manque " (si j'ose dire) de KonKyo qi ne comprend pas un truc genre dregs[dregs[IDX]], c'est ca? et du coup ya get pour compenser...
pour la struct kvm, ben ok mici ^^
pour les #define, ok c'est bien ce que je pensais, idem qu'en C quoi. je craignais qqch de pire...
voila voila
donc,merci énormément pour ce msg conséquent...
maintenant la question qui fache ^^ :
a part la simplicité de mise en place.... quels sont les avantages dee KonKyo par rapport a une dll écrite en C et donc plus abordable pour un débutant? voila c'est tout encore merci tout plein
la je suis sur un truc énorme donc pas le temps de faire une demo pour KonKyo mais quand je rentre de vacances je te fais ca promis ^^ a ce propos t'as une idée d'utilisation dans unn prog opengl ?
++
arno
7 juil. 2005 à 13:15
wow j'ai de la lecture ^^
bon je potasse ca et je te réponds OK ? ^^
mille mercis pour ces explications plus détaillées qu'aucune autres sur ce site...
++
ad
7 juil. 2005 à 11:12
"pour mettre un dreg en freg, ou l'inverse, je ne crois pas qu'il y ait une instruction x86 pour ca, donc a priori faut l' "émuler" , comment on fait? pasque l'IEEE c'est qd meme chiant comme format..."
Le bytecode creer par le compilateur KonKyo n'est pas un bytecode asm x86 mais un bytecode specialement concu pour la machine virtuelle de KonKyo, un peut comme un compilo Java qui creer du bytecode pour une JVM
pour mettre un dreg en freg ou vice-versa (convertir entier -> flottant ou l'inverse) il suffit d'utiliser l'instruction mov.
"pour la machine virtuelle, elle marche vraiement sous n'importe quelle plate-forme? tu parles de la GBA... par exemple ca pourrait marcher sous PSP?"
Pour le moment non, la machine virtuelle ne fonctionne que sur x86 et sous Windows, pour qu'elle fonctionne sur l'architecture que tu souhaite, il faut faire un portage, mais ceci ne devrait pas etre compliquer car je l'ai ecrit dans le but d'exploiter d'autre materiels, la plupart du code est assez standard je pense.
La seul complication pour les archi type GBA ou PSP, c'est que generallement il n'est pas possible de faire d'allocation dynamique de memoire, du moins sur GBA je sais qu'il n'existe pas de malloc (attention, ca existe mais c'est de la pure emulation et je ne sais vraiment pas se que ca vaut)
S'il existe une fonction malloc dans la libc d'un compilo pour PSP, alors il ne devrait pas y avoir de soucis, sinon, j'ai prevu a cette effet de pouvoir utiliser KonKyo sans allocation dynamique. En fait je crois ne faire qu'un seul malloc dans tout mon code, et c'est quand je lit le fichier de script compiler pour charger le bytecode en memoire.
Pour contourner cette solution, la seul chose a faire serait de modifier un peu la VM. La VM utilise malloc a deux reprise en fait, je viens de reverifier le code, elle le fait pour charger le bytecode comme je l'ai dit avant, contourner ceci est facile, il faut modifier la fonction kvm_set_script de la sorte :
(excusez le manque de coloration syntaxique mais je n'ai pas de Visual Studio sous la main)
int kvm_set_script(char *file, t_kvm *kvm)
{
char *ptr;
FILE *fd;
fd = fopen(file, "rb");
if (fd == NULL)
return (-1);
fseek(fd, 0, SEEK_END);
kvm->script_len = ftell(fd);
if (kvm->script_len <= 0)
{
fclose(fd);
return (-2);
}
fseek(fd, 0, SEEK_SET);
kvm->script_addr = malloc(kvm->script_len);
if (kvm->script_addr == NULL)
{
fclose(fd);
return (-3);
}
if (fread(kvm->script_addr, sizeof(char), kvm->script_len, fd) != kvm->script_len)
{
fclose(fd);
return (-4);
}
ptr = (char*)kvm->script_addr + read_prog_table(kvm);
kvm->script_addr = ptr;
fclose(fd);
return (0);
}
Il faut la modifier comme ceci :
(attention, le code suivant est ecrit a la pioche)
int kvm_set_script(void *bytecode_addr, int bytecode_len, t_kvm *kvm)
{
char *ptr;
kvm->script_len = bytecode_len;
if (kvm->script_len <= 0)
return (-2);
kvm->script_addr = bytecode_addr;
if (kvm->script_addr == NULL)
return (-3);
ptr = (char*)kvm->script_addr + read_prog_table(kvm);
kvm->script_addr = ptr;
return (0);
}
Aussi il faut virer le fopen, ce que je viens de penser, et donc de ce fait il faut faire le chargement du bytecode a l'exterieur de la VM et ensuite lui donner directement l'adresse du buffer contenant le bytecode.
Pour ce genre de chose, generallement ca ne pose pas trop de soucis, pour la GBA on avait ecrit un petit systeme de fichier donc pas de prob pour recuperer des fichiers, sinon vous pouvez compiler le fichier de script dans le programme et recuperer son addresse tout simplement grace au linker... enfin je me comprend.
Le plus gros probleme va etre au niveau de la fonction read_prog_table, qui creer une liste chainer de toutes les addresses des fonctions qui sont dans le bytecode. La, la modif est plus coton, ce qu'il faut faire basiquement c'est modifier le compilo pour qu'il compile un bytecode contenant une table d'addressage un peu particuliere, ayant un nombre d'elements fixe, et chaques elements ayant une taille fixe,
ce fait un bytecode tres gros pour des petits script, voir des script limiters si c'est pour de plus grosses envergures mais bon, l'idee serait de faire une table de 32 elements de 32 octets chacuns. Ansi le script serait limiter a 32 fonctions, et les fonctions seraient limiters a 32 caracteres, mais ceci permettrait a la VM de charger la table d'addressage du script sans malloc, et donc cela pourrait fonctionner sur n'importe qu'elle archi possedant un compilo C, meme un grille-pain... si quelqu'un a un grille-pain doter d'un processeur, biensure.
Pour ceci, ce n'est pas vraiment fastidieux comme boulot mais ca prend un peu de temps que je n'ai pas pour le moment, mais promis, si tu souhaite utiliser KonKyo en environement limiter (console de jeux, systeme embarquer, etc.. (truc ou y a pas malloc)) alors j'effecturais la modif dont je parle dans la doc et qui consiste a implementer ce que je viens de dire.
"dans les exemples que tu donnes touts tes résultats (et parametres) sont stockés dans des structures, est-ce obligatoire? a priori on peut utiliser deds tableaux statiques, pour les dynamiques apparament faut éviter, mais par exemlple c'est possible d'enregistrer la variable de retour d'un ss prog simplement dans un int ? (du style int résultat ; )"
Alors, non ce n'est pas obligatoire d'utiliser des structures, c'est juste que c'est plus simple quand tu code. Tu peux utiliser n'importe qu'elle element addressable, et ce qui est bien en C, c'est que tout est addressable :)
Tu peux utiliser un tableau statique (allouer en dure dans le code) ou un tableau dynamique (pointeur malloqué), aucun element ne pose de soucis a ceci pres que ton programme mere (celui qui integre la VM) doit gerer l'allocation dynamique de memoire, mais cela va de soit.
Tu peux tres bien aussi utiliser un int, pas de souci, tu peux tres bien faire ceci :
int param_and_result;
kvm_set_dregs(1, ¶m_and_result, kvm);
Au lieu de donner en parametre un tableau (qui est une addresse) ou l'addresse d'une strucutre, tu donne l'addresse de ton int et c'est regler. Je te rappel que l'addresse d'un int est un tableau d'int a un seul element ;)
int a;
int *tab &a;
int a[1];
int *tab = a;
donc pas de souci pour un seul int, tu peux meme faire ceci
char result[4];
kvm_set_dregs(1, (int*)&result, kvm);
ce qui aura pour resultat de recuperer une valeur 32 bits et directement decouper dans 4 octets distincts, pratique pour recuperer une couleur RGBA par exemple. Ceci dit, attention a l'endian de l'archi sur laquel tu travail.
"tu pourrais réexpliquer non pas le fonctionnement mais l'utilité de get et de set ? pasque ton explication initiale , ben.... j'ai rien calé ^^"
Desoler, c'est vrai que c'est pas evident car c'est le genre de chose que je n'avais helas pas penser quand j'ai commencer la phase d'extreme programming (arf!) et donc j'ai due "bricoler" pour arriver a mes fins, la facon de faire n'est pas du tout elegante mais bon, c'est comme ca, on va dire que plutot qu'une erreur de conception, c'est une implementation qui fait que KonKyo ce demarques des autres assembleurs :P
Ces instructions servent a definir ou obtenir des valeurs d'un registre via un index, sans ses instructions, toutes notions de boucle tombe a l'eau, et le scripting perd tout son sens. Un exemple tres simple :
int i;
for (i = 0; i < len; i++)
tab[i] = val_init;
imagine qu'il serait impossible d'acceder a la case i du tableau tab mais qu'il aurait fallu faire
tab[0] = val_init;
tab[1] = val_init;
tab[2] = val_init;
etc...
l'informatique ne serait pas la ou elle en est aujourd'hui, et tot ou tard quelqu'un aurait inventer une "bidouille" pour automatiser le truc. Heureusement des gents ont reflechis plus longtemps que moi et on permis l'addressage, ce qui permet de modifier une valeur a une addresse x, d'incrementer x et de recommencer. C'est ce que permette globalement get et set, j'explique desormais, desoler pour ce long intermede.
Dans la doc, j'ai ecrit ceci : "L'instruction get prend deux parametres, ils doivent absolument etre de type registre, et le deuxieme doit absolument etre un registre decimal".
Le premier registre est uniquement la pour donner/recevoir la valeur qui se trouve dans un registre i, et i est indiquer par la valeur contenu dans le deuxieme registre.
mov dreg[1], 5
get dreg[0], dreg[1]
traduction en C :
int dreg_1 = 5;
dreg_0 = get_register_value_at_index(dreg_1);
si tu veux mettre le contenu du registre 50 dans le registre 0, tu peux faire ca
mov dreg[0], dreg[50]
ou ca
mov dreg[3], 50
get dreg[0], dreg[3]
dreg[3] contient 50, et donc get va chopper la valeur du registre 50 et la mettre dans dreg[0]. L'avantage de cette methode, c'est que dreg[3] peut etre incrementer, ensuite avec un bouclage, on ira lire la valeur du registre 51, et ainsi de suite. Un exemple avec set :
mov dreg[IDX], 0
[code de bouclage]
set 0, dreg[IDX]
inc dreg[IDX]
[code de test de fin et rebouclage]
j'ai zapper le code de bouclage et le test de fin, mais ce qui se passe, c'est que dreg[IDX] (IDX est un define, ca pourrait etre 300, on s'en fout) est initialiser a 0, donc il "pointe" le registre 0 (dreg[0]), ensuite set met a 0 le dreg[0], ensuite on incremente le dreg[IDX] qui passe donc a la valeur 1, par consequent il "pointe" desormais le registre 1 (dreg[1]) et set le met a 0 et ainsi de suite. Traduction en C :
memset(register_tab, 0, register_tab_len);
libre a toi de faire
mov dreg[0], 0
mov dreg[1], 0
mov dreg[2], 0
etc...
mais c'est franchement moyen comme solution si tu veux initialiser un espace memoire.
"la structure kavm que tu utilises, on en a 1 et 1 seule , ou 1 par script, ou 1 par appel aux fonctions de ta lib ?"
Tu en as une par machine virtuelle que tu veux avoir :) Tu peux en utiliser autant que tu veux. Tu peux n'utiliser qu'une seul VM si tu veux et executer autant de script et de fonctions que tu veux avec une seule.
Tu peux modifier la pile et les registres a la voler dans ton programme mere, tu peux a un moment donner dire "ce script fait une tache en recursif, il a besoin d'une pile plus balaise, par consequent je redefinit le pointeur de pile sur un tableau plus grand, quand j'aurais fini, je redefinirais ma pile sur mon precedent tableau pour ne pas perdre les donners d'avant", c'est une philosophie parmis tant d'autres ;) mais il y a aussi la philosophie
"je creer un seul espace memoire qui sera commun a tout le monde, mais je creer deux pile, et deux VM, chaque VM recoit une pile distinct et le meme espace memoire, ensuite je balance une fonction simple sur une VM, et une fonction recursive (qui peux se trouver dans le meme script que la fonction precedente) sur mon autre VM" dans ce cas ce n'est pas vraiment utile, mais tu peux avoir plein de script/fonctions qui tourne en meme temps, ayant des espaces memoire propre et des piles propre a eux-meme,
et par consequent il est plus pratique de creer plusieurs "environements" en creant plusieurs VM, tu leur attribue leurs espaces memoire, leur pile, et apres tu balance le script et la fonctions que tu veux sur "l'environement" (VM) que tu veux.
Un meme script peut etre charger dans 2 VM differentes sans probleme, les VM peuvent appeler la meme fonction et peuvent meme travailler sur un espace memoire commun, deux script different peuvent etre charger dans la meme VM (attention il ne peuvent tourner que concurentiellement, il faut charger le nouveau script qui decharge l'ancien, puis recharger l'ancien, ce qui peut encore montrer qu'il y a du bon a utiliser plusieurs VM), enfin pour resumer, on peut executer ce qu'on veut, comme on veut et quand on veux de la facon qu'on veut, pratiquement aucune limites a se niveau la.
Je viens de dire une grosse connerie :S je viens de relire mon code et la fonction kvm_set_script ne desaloue pas la memoire allouer par un eventuel precedent chargement, ce qui n'est pas grave d'un point de vue fonctionnel, mais aussi il ne detruit pas l'ancienne table d'addressage, et comme c'est une liste chainer, il rajoute les elements. Une petite modif tres simple pourrait palier le probleme, je patcherais le code quand j'aurais un peu de temps.
"je n'ai pas bien saisi l'intéret de faire des #define pour tous les index des tableaux..."
Bah c'est comme un C, des fois il y a des valeurs que tu ne te souvient pas leur signification, par exemple dans un script tu va utiliser le registre 300 comme registre temporaire qui te servira a faire des echange donner, des initialisation ou autre, si dans ton code tu utilise dreg[300] et que tu relit ton code 6 mois plus tard ou que tu passe le script a un collegue, il comprendra pas forcement, par contre si tu fait ceci
#define TMP 300
...
mov dreg[TMP], 0
...
la tout devient plus claire non ? de plus si un jour tu modifie la configuration de la VM et qur tu travail avec 200 octets de memoire, tu sera bien content de n'avoir a changer la valeur de ton registre temporaire qu'une seul fois via
#define TMP 199
au lieu de le changer partout ou tu t'en sert, ce qui serait bien plus chiant a faire :)
"au fait le projet a évolué ou t'as laissé tomber ?"
Le projet n'as pas evoluer et je ne l'ai pas laisser tomber, via tes questions, ca a lever le voil sur le rechargement d'un autre script dans une meme VM, pour lequel je ferais tres certainement une correction, et pour d'eventuelles modifications/evolutions majeur, je prefere attendre d'avoir une demande forte pour m'y coller, je sais que ce n'est pas la bonne philo, mais je ne veut pas bosser sur un code s'il n'est utile a personne alors que pour le moment je pourrais me consacrer a des projets bien plus interessant.
Donc voila, pas d'evolutions majeur, mais le projet n'est pas enterrer et ne demande qu'un bon coup de fouet ;)
J'espere avoir repondu le plus clairement possible, et j'espere aussi que tu n'es pas le seul a avoir profiter de mes explications.
Bonne journée a toutes et a tous
28 juin 2005 à 17:18
mais réponds qd meme
28 juin 2005 à 16:28
25 juin 2005 à 22:06
chose promise chose dûe
j'ai relu toute la doc, si si, les 37 pages, et j'ai quelques questions.
allons-y:
o pour mettre un dreg en freg, ou l'inverse, je ne crois pas qu'il y ait une instruction x86 pour ca, donc a priori faut l' "émuler" , comment on fait? pasque l'IEEE c'est qd meme chiant comme format...
o pour la machine virtuelle, elle marche vraiement sous n'importe quelle plate-forme? tu parles de la GBA... par exemple ca pourrait marcher sous PSP?
o dans les exemples que tu donnes touts tes résultats (et parametres) sont stockés dans des structures, est-ce obligatoire? a priori on peut utiliser deds tableaux statiques, pour les dynamiques apparament faut éviter, mais par exemlple c'est possible d'enregistrer la variable de retour d'un ss prog simplement dans un int ? (du style int résultat ; )
o tu pourrais réexpliquer non pas le fonctionnement mais l'utilité de get et de set ? pasque ton explication initiale , ben.... j'ai rien calé ^^
o la structure kavm que tu utilises, on en a 1 et 1 seule , ou 1 par script, ou 1 par appel aux fonctions de ta lib ?
o je n'ai pas bien saisi l'intéret de faire des #define pour tous les index des tableaux...
o j'avais encore qques questions mais je m'en souviens plus :D ca reviendra.
merci de tes réponses, surtout plusieurs mois apres.... au fait le projet a évolué ou t'as laissé tomber ?
voili voilou,
++
Arnaud
18 avril 2005 à 17:11
Sinon merci pour le lien, je vais jetter un coup d'oeil.
18 avril 2005 à 15:38
Sinon le fait de mettre en debug ne changera rien à l'affaire. Le mode debug donne quelques infos quant à l'endroit dans les source où se trouve un bug, le nom de la fonction, ... mais ils ne se trouvent en aucun cas dans la table des exportations. Si tu as un peu travailler sur des PE tu devrais savoir où se trouve la table d'exportation sinon voila un bon petit lien : http://spiff.tripnet.se/~iczelion/files/frenchtuts.zip
18 avril 2005 à 14:05
C'etait trop facile :P
18 avril 2005 à 13:52
http://www.dependencywalker.com
cet outil est vraiment mortel, mais en effet, il ne donne pas les noms des fonctions, juste les dependences.
je ne sais pas si on peut loader un .exe comme une DLL avec LoadLibrary, je vais tester de se pas, mais si on peut, ca serais vraiment trop mortel :)
18 avril 2005 à 13:35
?!?!
Dependecies ne trouve rien dans un exe... Tout ce qu'il trouve c'est les imports/exports. Sinon je c qu'on peut exporter des fonctions a partir d'un exe (Fait un view dependecies sur excel.exe par exemple). Mais je ne sais pas trop comment on fait. Ca doit être assez semblable à une dll.
Ensuite tu peux utilisé les API windows (LoadLibrary,...) pour appeler la fonction.
18 avril 2005 à 13:34
Lol, a mon avis, si tu utilise KonKyo tu va avoir des surprise, c'est un peu special quand a l'utilisation des registres et de la memoire, mais je suis tres flatter de ta proposition, et serait honorer de voir un projet utilisant KonKyo :)
Je l'ai developper en un mois et demi mais a temps plein, pas d'ecole, pas de boulot :) donc franchement, c'est jouable, ca n'as rien d'extraordinaire.
18 avril 2005 à 11:03
Et encore, on est pas vur vbfrance, la bas une source postée un jour n'est déja plus sur le sommaire le lendemain, tellement ca enchaîne vite...(alors que sur asmfr...lol)
faut dire que le titre de ta source doit etre assez décourageant pour un débutant ;)
hein? c'est quoi asm? mdr
en tout cas , en ce moment je ne suis pas (plus) dans openGL, (en fait je développe ma propre implémentation d'openGL :D )mais dès que j'y reviens, je m'engage a faire un prog qui utilise KonKyo, histoire que tout le monde en profite (ben ouais pourquoi yaurait que Funto qui ferait des trucs que tout le monde réutilise, C pas juste mdr)
Et j'ai du mal a te croire... 1mois et demi!!! ouahw... respect ;)
++
ad
ps: t'as écrit tout ca a 2 heures du mat' ???? ouah le ouf...
18 avril 2005 à 01:45
sibi12, cette methode est correcte mais elle ne me plait pas trop, ca impose beaucoup trop de contrainte au programmeur dans son code C, je suis ok avec l'idee de la macro, mais l'ideal serais d'arriver a parser le PE (Portable Executable) et tenter de determiner les proto des fonctions directement. J'ai deja bosser sur le PE mais vraiment trop peu, et je croyais que les metadonnees n'etait pas stocker dedans mais... je viens seulement maintenant de me poser la question suivante : comment "depends" fait-il pour trouver les metadonnes dans un executable 'release' ?
J'en ai deduis que ces metadonnes sont belle et bien quelque part ou je n'avais pas chercher, et donc je commence a me renseigner sur le format, je suis convaincu que ce genre de recherche, meme si elle n'abouti en rien pour KonKyo peut etre d'une grande richesse pour d'autres developpements futur :)
Enfin bon, l'idee de la structure contenant toutes les informations de la fonction n'est pas ecarter, mais je la met en standby pour tenter de trouver quelquechose qui serait plus confortable pour le programmeur.
La VM ne possede que 5 fonctions, 1 fonction pour le chargement du script, 3 fonctions pour recuperer des information concernant la memoire (une pour les registrers d'entier, une pour les flottant et un pour la pile) et 1 fonction pour executer le script. En gros, on peut executer un script avec un minimum de 4 appel de fonction, c'est tout. Le but est d'avoir une simpliciter de mise en place et d'utilisation le plus optimal possible.
Kirua, je ne savais pas que LUA interpretais :S c'est bizarre pourtant car beaucoup de grosse l'utilise dans des developpement de grandes envergure.
"Le truc, c'est que Lua ne précompile pas ;) Donc tout peut s'adapter au run time."
Le compilateur de KonKyo est en fait un programme qui fait appel a ma lib de compilation kcc (KonKyo Code Copiler ;)) donc je te laisse imaginer qu'en tres peu de temps, tu peux avoir une compilation du script a la voler, au cours du runtime :P mais bon je vois pas trop ce que ca change... le code natif (programme mere) ne modifie pas le script (pour LUA) au runtime donc qu'elle est l'interet de pouvoir adapter le script au runtime ?
"le nombre de params est tjs 1! mais on passe ce qu'on veut :)"
Oui ca semble evidant, void* et on file l'adresse d'une structure dans laquel on met ce qu'on veut, faudra que je reflechisse si c'est mieux de faire ainsi ou de tenter de respecter les proto des fonctions natives.
Arnaud, tout d'abord merci pour tes encouragements, ca fait vraiment plaisir et tu n'es pas loin de la veriter sur pas mal de point :)
"Un gusse a passé 6 mois voire plus de sa vie..."
heu... voir moins ^^
Ce developpement m'as pris un mois et demi complet, mais serieusement, quand vous regarderez le code, vous comprendrez :S dans l'ensemble il est tres bien ecrit, mais le module d'interpretation du bytecode me fait honte tellement il est degueulasse :S enfin bon, j'espere que, me pardonnerons et comprendons, ceux qui verront :P
"les sources comme celles-ci passent completement inapercues"
En effet il y a beaucoup trop de "mon prog explique comment utiliser printf" :S mais je sais que Nix en a pris conscience et les admins bosse sur le sujet, d'un autre point de vue, je me met a la place de l'admin qui rentre le soir apres une journee toute aussi dur que la notre, sauf que lui en plus de ses mails a lire et tout et tout, il a "en plus" 300 messages/posts a moderer/filtrer...
Je ne pense pas non plus qu'il faut blamer ceux qui postes des trucs moyen, apres tout il faut laisser tout le monde s'exprimer... meme si ca pose des problemes, il faut de tout pour faire un monde...
Bref, j'ai largement depasser le sujet original du post. Enfin ca me fait quand meme plaisir de voir que des gens s'interesse a mon travail :) Encore merci a vous tous, et n'hesitez pas a continuer de faire tourner vos idees ;)
17 avril 2005 à 23:49
Un gusse a passé 6 mois voire plus de sa vie a coder un projet génialissime/énorme/gigantesque/merveilleux, et on est 4 sur son forum.
1: seb, un grand bravo
2: les admins: je pense qu'un des pbs de Codes-Sources est que les excellentes sources comme celles-ci passent completement inapercues. c'est dommage, un programme comme ca tous les programmeurs openGL (et plus) qui ont dépassé le stade glVertex3f() pourraient s'en servir et faire des choses super avec
Excellente continuation.
Si je pouvais te mettre 20/10, je le ferais sans hésitation (et c'est pas la premiere fois que ce genre de chose arrive :( )
++
16 avril 2005 à 22:55
Autre chose pour les params: on ne peut passer et recevoir que des tableaux -> le nombre de params est tjs 1! mais on passe ce qu'on veut :)
16 avril 2005 à 22:52
Ca complique un peu le code en C mais on peux créer une macro qui fait le boulot.
16 avril 2005 à 22:30
Parceque si c'est le cas, integrer les appel de fonction native devrais pas etre trop compliquer, mais reste le probleme du passage de params, et la faut tout controler car ni le compilo C ni le compilo KonKyo ne pourront savoir a l'avance si on a bien donner le bon nombre d'arguments, et sans controle, c'est super dangereux pour la securiter :S
En tout cas merci bcp Kirua, je garde ce tips en tete ;)
16 avril 2005 à 21:36
GetNbPotions ...;
Ce qui est vite devenu fastidieux vu le paquet de données!
En réalité, un script qui tourne "en lui-même", sans interagir avec l'hôte peut être intéressant pour reléguer certaines parties du code sujettes à changer souvent à des script. Par exemple, pr un programme de stats où on veut souvent changer la manière de calculer les résultats, on peut désirer scripter: on passe les valeurs et on récupère le résultat. Mais dès qu'il s'agit d'un jeu, le script lance des boîtes de dialogues, a besoin des réponses du joueur etc etc: c'est bcp plus intense comme trafic.
Autre chose: avec Lua, on passe des pointeurs sur fonction ;) vas-y donc gaiement :)
16 avril 2005 à 18:58
de plus KonKyo est fait pour lancer des scripts vraiment petit (du au fait qu'il est vraiment tres bancale :S) donc je ne sais pas si c'est vraiment necessaire de rajouter le fait de pouvoir appeler du code natif de l'application mere
faudrais faire un sondage :P
16 avril 2005 à 18:56
en fait en ASM,
push eax
push ebx
call func
équivaut à
invoke func, ebx, eax
et invoke est une macro déclaré comme plus haut.
16 avril 2005 à 18:49
ben dans un code C si tu veux placer plusieurs argument sur la pile ca donne plus ou moins ca (avec la convention STDCALL et pas testé) :
int nbarg;
int[] arg;
int ret;
int *func;
....
__asm
{
mov ecx, nbarg;
mov ebx, arg;
boucle:
push [ebx+4*ecx]; // si mes souvenir sont bon, on push le dernier argument en premier mais je suis plus trop sûr donc si quelqu'un peut confirmer.
loop boucle;
}
ret = func();
si je me suis tromper pour la convention on rajoute après mov ebx, arg, lea ebx, [ebx + 4*ecx] et push [ebx+4*ecx] devient push [ebx-4*ecx].
pour le invoke ce que je veux dire c'est créer des macro qui te "génére ton code" avec le push et tt ca avt. pour MASM, dans Object.inc, on a ca :
; --=====================================================================================--
; $invoke()
;
; This macro accelerates the normal invoke macro for inline coding. It creates the exact
; same code as invoke does.
;
; SYNTAX: mov hAnyReturn, $invoke( function [,args] )
;
; RETURN: eax = The any return from function
;
; CODE GENERATED:
;
; invoke function [, args]
; mov hAnyReturn, eax
; --=====================================================================================--
$invoke MACRO Fun:REQ, A:VARARG
IFB
invoke Fun
else
invoke Fun, A
endif
exitm <eax>
ENDM
Enfin c'est vrai que si tu a fait du ASM-like c'est pour la simplicité du parsing donc cet idée est peut-être à écarté mais je propose toujours. Par ailleur, il me semble que IF, else,... sont des MACRO aussi mais je ne le jurerai pas.
16 avril 2005 à 17:41
c'est ce dont j'ai parler, un tableau de pointeur sur fonction, un tableau est deja un pointeur, je ne voit pas l'utiliter d'avoir un pointeur vers un tableau.
je pensais aussi a la possibiliter du __asm, mais le probleme c'est que je n'y connais rien en asm x86 ni en interaction C/ASM, j'imagine que :
int a = 3;
__asm
{
mov sp, a
inc sp
}
ne fera rien de bon, de plus la syntaxe des mneumonics n'est pas correct vis-a-vis de l'x86, j'imagine.
je ne connais pas la macro invoke, mais n'hesite pas a developper ton idee d'avantage, le progres, peut importe la direction qu'il prend reste un progres :)
16 avril 2005 à 17:09
Sinon pour appeler des fonctions, l'idée du pointeur est pas mal et je propose meme mieux : un pointeur vers un tableau de fonctions (un pointeur vers un tableau tout court peut être interessant aussi en dehors de la question d'appel de fonction).
Pour l'appel avec des paramètres je crois que le plus simple est un petit block __asm et pour les differentes convention d'appel tu peux utilisé un préfixe. tu aurais STDCALL, APICALL,...
ou bien carrément reprendre l'idée de la macro invoke pour ne pas devoir la coder en dur.
16 avril 2005 à 14:27
Le choix du ASM-like et non pas Basic-like ou C-like pour le language est tres simple, l'ASM c'est mega simple a parser, on lit ligne par ligne, chaque ligne est independante, pas de bloc, pas de syntaxe farfelu :P
Si quelqu'un a une bonne methode pour parser du C, je suis preneur :)
16 avril 2005 à 14:25
pour ceux interesser par une forme plus evoluer de scripting (C#) pour les applications .NET, j'ai poster une source assez interessante ici :
http://www.csharpfr.com/code.aspx?id=30542
Ca permet d'utiliser les fonctions de compilation de code interne au CLR pour compiler du code a la voler et se linker ensuite dessus durant le runtime.
Aussi, toujours dans le sujet du scripting, je suis en train de refaire KonKyo from-scratch en C#, mais ce coup-ci en evitant les fantaisies stupides quand a l'utilisation de la memoire et des registres :)
Etant un peu charger en ce moment, ce projet ne risque pas de voir le jour de si tot, mais je compte bien le sortir quand meme.
16 avril 2005 à 14:18
Pour echanger des donnees programme/script, c'est super simple, quand tu "instancie" une VM dans ton programme, tu donne a la VM un pointeur sur int, et ceci sera la memoire de la VM, tout ce que le script ecrira sera stoquer la dedans.
Donc tu creer un tableau, tu lui donne les valeurs que tu veux, tu le file a la VM et quand le script s'execute, il peut ainsi lire les valeurs et les modifer, a la fin du script, les valeurs auront ete modifer par le script mais dans l'espace memoire du programme, il ne suffira plus que de lire les nouvelles valeurs du tableau.
Par exemple aussi, et c'est aussi ecrit dans la doc :) on peut declarer une structure avec trois int, 2 servant de parametre et un 3 eme de resultat, et ensuite on passe l'adresse de la structure a la VM avec un cast, exemple :
(int*)&my_struct
car apres tout, en terme d'allocation memoire, les elements d'une structure sont toujours contigues, donc une structure ne possedant que des int est, en memoire, un tableau d'int :)
Pour ta deuxieme reponse Kirua, et bien j'ai le regrais de dire que ce n'est helas pas possible :( J'etais en train de bosser sur la question mais je me suis heurter a un probleme d'ordre architectural. Je pense que BruNews pourrait surement m'aider sur ce coup la.
Mon premier probleme etant qu'a la compilation du script, le compilo en voyant un appel de fonction devrais aller recuper l'adresse de la fonction du programme, ce qui implique que le script est etroitement lier au programme, ce qui n'est pas souhaiter, de plus il faudrait recompiler le script a chaque fois qu'on recompile le programme. Pour se probleme, je ne sais pas comment recuperer l'adresse d'une fonction dans un exe a moins d'avoir le fichier de debug qui contient les metadonnees.
Autre solution, je pourrais garder le nom de la fonction dans mon script, et chercher l'adresse de la fonction dans le programme appelant au moment de l'execution du script, mais je me retrouve facer au meme probleme, j'ai un nom de fonction mais qui n'ai pas contentu dans l'exe :S donc assez cotton pour recuperer l'adresse de la fonction.
Je pourrais palier se probleme a l'aide d'un bricolage de troisieme rang, qui consiterais a donner a la VM une liste de "pointeur sur fonction", et ensuite dans le script on ferais func[0], func[1], func[n] etc... mais c'est pas terrible, et je pense que personne ne me contredira non plus la dessus ;) et bon, meme si cela etait envisageable, le second probleme casse tout :
2eme probleme:
Je ne sais pas comment faire, techniquement, pour ecrire dans la pile et lire la pile pour passer mes parametres au fonction appelees et recuperer un retour, et meme si je savais, reste encore le probleme architectural... il faudrais etre super specifique vis-a-vis de l'archi sur laquel tourne la VM, et de ce fait il me faudrais modifier la VM pour chaque archi differente.
Comme vous pouvew le constater, une pletore de probleme demeure :) mais si on peut rassembler une troupe de barbares motiver pour mettres les mains dans le camboui, je suis partant :)
J'ai donner le source pour quiconque voudrais voir plus ou moins comment ca fonctionne, mais aussi pour que quiconque veuille le faire evoluer puisse le faire :)
16 avril 2005 à 13:59
Je n'ai pas utiliser le concept objet car je voulais realiser mon projet en C, je l'ai dit ca fait partit des choix de depart :) une lib en C peut etre integrer a un projet C comme C++, une lib developper en C++ ne peut etre integrer que dans un projet C++ et penalise de ce fait les projet C et la plupart des projets embarquer.
Pour ce qui est de mopn Francais, c'est claire que c'est pas gagner, mais rassure toi c'est parceque je vait vite, mes CV et lettres de motivations ressemble pas a ca :P
Sinon pour les accents, je sais que c'est merdique, je suis desoler mais c'est parceque j'utilise un clavier qwerty et se tapper des Alt+133, Alt+130 etc.. a longueur de temps, on fini par ecrire en phonetique :P
"je doute que bcp de gens scriptent leurs jeux dans un asm-like (contredisez-moi mais..."
Non non je ne te contredirais pas Kirua :) mais ca peut etre une experience enrichissante, et c'est claire que pour le milieu de jeux video professionel, je compte pas detronner LUA avec mon pauvre projet :)
"j'imagine que pr des systèmes embarqués le C s'impose, je me trompe?"
Le C s'impose en effet, cependant il existe pas mal de systeme embarquer possedant des compilateur C++, par exemple il existe une version de g++ pour GameBoay Advance, ce qui permet de developper sur ce petit missile de console en C++
16 avril 2005 à 12:53
j'ai lu un bout de la doc, c'est assez fort! je doute que bcp de gens scriptent leurs jeux dans un asm-like (contredisez-moi mais ... enfin, perso j'utilise plutôt un basic-like ou encore un c-like). il n'en reste pas moins que le travail est immense, et le résultat époustouflant! comme le disait Xs, de la prog orientée objet aurait aidé à la clarté et à la factorisation, mais j'imagine que pr des systèmes embarqués le C s'impose, je me trompe? (je n'en sais trop rien à vrai dire).
une question (c'est sûrement ds la doc mais j'ai pas tt lu): si j'implémente ton langage de script dans un de mes programmes, quelles sont les procédures pour
1/ récupérer depuis le script des données du programme hôte
2/ appeler depuis le script des fonctions du programme hôte
Bonne journée à toi!
15 avril 2005 à 16:53
mais un seul mot viens : respect.
15 avril 2005 à 12:18
- Tu n'as pas utilisé le concept d'objet, ce qui t'aurais permis d'être plus clair et plus efficace (certainement). Notamment dans s_kvm.
- Ton Français : les fautes entre "é", "er", "ez", etc...
Mais bon, ca ne change rien au fait que ton code est génial (au sens 1er du terme).
Cordialement
15 avril 2005 à 12:13
Félicitations. 20/10.
Cordialement