[mOved] Venez voir ca! un compilateur basic pour les ti - Page 4

Nous comptons faire ça pour TIGCC, mais c'est un projet à long terme pas encore commencé.

et après, tu viendras te plaindre que Pollux parle de GTC dans tous les topics ...

topics/18104-gtc-un-tigcc-sur-votre-calculatrice/2#33

Bientôt = en années? ^^

#90> Oui, j'aimerais qu'on reste dans le sujet (comprendre: pas de troll GTC/TIGCC) merci.

Ximoon: ./92 aussi alors... d'ailleurs c'était "Un attaque personnelle contre Pollux"

J'ai oublié: pas de commentaire...

Flanker
:

Nous comptons faire ça pour TIGCC, mais c'est un projet à long terme pas encore commencé.

et après, tu viendras te plaindre que Pollux parle de GTC dans tous les topics ...

Ben, nous avons déjà réfléchi sur la question et lui apparemment pas vraiment, donc je lui dis ce que nous comptons faire. C'est juste un conseil, rien de plus. Désolé si ça a été mal pris.

#92 et #94 t'en fais quoi ?
Tu me prends pour un con ?

Ximoon :
#92 et #94 t'en fais quoi ? Tu me prends pour un con ?

C'est toi qui me prends pour un con en rajoutant une couche alors que je viens de présenter mes excuses ("Désolé si ça a été mal pris.")...
Je pensais donner une information intéressante, c'est Vark qui a fait partir le tout en ******* avec sa remarque...

Soit.

nTOME: pour ton compilateur basic, a propos des listes et de l'allocation, tu pourrais faire qu'on cree en donnant un ordre de grandeur du nombre de cases, et que le nombre sera rehausse s'il le faut (ptet que cette idee t'es deja venue a l'esprit)


Onur » nTOME: ben.. non jy avais pas pensé. Merci de ta proposition. On pourrait en effet faire une syntaxe qui fait en sorte que ca l'initialise a une certaine taille et on avertira l'utilisateur (si jamais il l'est pas) que l'allocation dynamique peut etre lent. BIen vu. Je te promets pas que je le ferai mais ca me semble une bonne idée! merci encore

naPO :
J'ai essayé d'installer ETP-Basic Compiler, et il utilise un mscomctl.ocx trop récent -> ça marche pas, génial Onur
• naPO est dégoûté

Ouais, j'ai une idée. Dans ton dossier system: C:Windows:system je crois, en tout cas le dossier qui contient tous les ocx,dll et compagnie.. eh ben dans ce dossier, si tas déja mscomctl.ocx tu le coupe et tu le colles ailleurs. Et dans ce dossier, tu mets le mscomctl.ocx livré avec le zip que t'as téléchargé. Y a plus qu'à prier.

Et modifie aussi le fichier du dossier lastgood (dans windows).

en fait jai testé ce que je vien de dire a naPo mais ca marche pas non plus. donc donne moi ton mail, je vais tenvoyer une version spéciale. en fait je vais tenvoyer le ETP-Studio avec tout le IDE qui nest pas fini mais y a le compilo ki est fini donc tu pourra lutiliser.

Kevin Kofler
:

Onur :

faudrait compiler ligne par ligne et l'envoyer a un emulateur

Non. Faudrait compiler en incluant des informations de débogage et implémenter la gestion des informations de débogage dans l'émulateur. Nous comptons faire ça pour TIGCC, mais c'est un projet à long terme pas encore commencé.

Pourquoi ne pas passer par GDB et son fonctionnement en 'remote debugging', comme a essayé de le faire Nitro avec TIGDB ? Ca économiserait beaucoup de boulot.

On a déjà l'IDE qui doit communiquer avec l'émulateur, on n'a vraiment pas besoin d'un troisième logiciel (un débogueur remote) pour compliquer encore plus les choses.

Et en plus, il y aurait pas mal de choses à modifier dans GDB pour le faire marcher comme on veut. (Les hacks de nitro ne sont pas fiables du tout.)

Je sais que je post un peu tard, mais je voulais juste encourrager Onur à continuer ses efforts ! Bravo ! Je vais jetter un coup d'oeuil au compilateur quand j'aurrai le temps, mais d'ici, ça semble asssez clean.

Merci ca fait trop plais'
.. en effet cest pqs du tout evident de faire un compilo de A à Z.

Onur :
Merci ca fait trop plais'
.. en effet cest pqs du tout evident de faire un compilo de A à Z.

Je sais, t'es pas mal courageux de t'avoir lancé dans un tel projet. Félicitations encore une fois !

Kevin Kofler
: (Les hacks de nitro ne sont pas fiables du tout.)

Il utilise des hacks ? Je pensait que c'était simplement une implémentation du protocole série de GDB exécutée par le programme (qui là pourrait être effectuée par l'émulateur), et un serveur TCP qui utilise libticables pour rediriger le dialogue vers VTI.
Ce que je me dis c'est que pour arriver au niveau de GDB, il faudra beaucoup de boulot.

ExtendeD
:

Kevin Kofler
: (Les hacks de nitro ne sont pas fiables du tout.)

Il utilise des hacks ? Je pensait que c'était simplement une implémentation du protocole série de GDB exécutée par le programme (qui là pourrait être effectuée par l'émulateur), et un serveur TCP qui utilise libticables pour rediriger le dialogue vers VTI.
Ce que je me dis c'est que pour arriver au niveau de GDB, il faudra beaucoup de boulot.

L'idéal c'est d'implémenter le stub de communication dans l'émulateur, là où c'est fiable à 100%, et pas dans le programme qui tourne. A l'époque j'avais pas le bon compilateur pour modifier VTI, alors j'avais choisis de le mettre dans le programme...

C quoi le "programme qui tourne" ? Le client pour GDB ?

Le programme que tu veux débugger.

Le programme émulé par VTI (edit : croisé)

Comment ça fonctionnait ? Interruption qui reçoit les données de GDB ?

Ca fonctionnait avec le link, donc on pouvait même l'utiliser pour débugger sur une vraie TI, pas nécessairement VTI.
Insight / DDD / KDBG / ... <--- GDB/MI ---> GDB <--- TCP/IP ---> TI-GDB <--- LINK (libticables) ---> TI / VTI

Mais le seul code supplémentaire venait de l'autoint 4, nan ?

Il y avait aussi des hacks comme l'utilisation du mode trace pour pouvoir faire du single-stepping.
Et il fallait modifier la source du programme et le recompiler pour rajouter l'instrumentation de débogage (beurk!).