GFA-Basic et Pedrom - Page 2

Oui c'est un peu plus rapide, tu peux tester par toi même.
J'ai fait des tests internes à GFA-Basic avec des chaînes de caractères:

Avec chaîne de 56 caractères sur adresses paires:
memcpy = 1371
routine GFA = 1466

Avec chaîne de 55 caractères sur adresses impaires:
memcpy = 1340
routine GFA = 1369

Donc bien sûr le gain sera bien plus important normalement.

C'est quoi les unites ?

strings/secondes.

Etonnant. Je bencherai des que je pourrai.

Je suis sûr que tu trouveras moyen d'optimiser mon code parce que tu dois te dire, vu la taille ça doit pas bien être rapide.

J'essaye deja de le compiler, et je n'y arrive pas.

Ah? Qu'est-ce qui bloque?

Ben quoi ? Je peux pas compiler sans ces fichiers

Tu peux télécharger les sources... ici: http://www.tigen.org/gfabasic/index.php?page=download&file=GFA-Basic2.zip&ref=GFA-Basic2

Mais bon faut bien comprendre que dans le projet:
GFA-Basic=Scanner, parser, tokeniseur... Projet en C.
GFA-TEM=Interpreteur du code produit avec GFA-Basic. Projet en ASM A68K.

C'est temporaire tout ça, à la fin il n'y aura plus aucune distinction.

Il n'y a pas de repertoire Functions, System et Other dans cette archive.
Bon je vais voir ce que je peux faire quand meme.

Ah ouai je vois, c'est à cause des dossiers réalisés dans le projet sous TIGCC. Je te fais un pack si tu veux bien.

Voilà, normalement ça devrait aller. Tu n'auras pas ce genre de pb avec GFA-TEM!
http://tisofts.free.fr/GFABasic/gfa_pedrom.zip

Merci. JE vais essayer.
C'est vraiment top les TPR pour la distribution de code

Bon ca marche. Mais ca serait bien de rajouter des lignes vides a la fin

Si tu pouvais faire deux petites choses deja:
1. Mettre un prefixe devant toutes les variables globales:

EXTERN unsigned short errnum;

--> Les variables globales doivent etre dans la RAM.
2. Dans main.c si tu pouvais separer parfaitement l'application du recuperage de parametre
(parce que les fonctions internes ne doivent pas acceder a l'estack pour lire les entrees)
3. Dans Header.h:

#ifdef PEDROM

#ifndef EXTERN
#define EXTERN
#endif
#include "PedroM-Internal.h"

#else

#include <tigcclib.h>

#endif

(3 en fait donc).

Je pourrais le faire, mais ca ferait des versions concurentes, et tout ca, donc conflit de version, pas beau.

Ok je vais regarder tout ça ce soir.

Mais bon faut bien avoir à l'esprit que le code de GFA-Basic est temporaire. D'ailleur ça se voit dans les sources, les ajouts, les modificaiions, les fichiers avec du code en commentaires en témoigne.

Sinon une petite question, est-il possible sous PedRom, d'executer un fichier en archive sans que PedRom fasse une copie en RAM? Car ça serait bien plus facile pour moi de tester. Que de à chaque fois, envoyer une ROM! (Je sais y a VTI mais bon tester sur Real TI c'est bien mieux des fois).

Et utilise tout le temps Header.h dans les fichiers .c, ca sera plus simple de patcher tout ca.

>Sinon une petite question, est-il possible sous PedRom, d'executer un fichier en archive sans que PedRom fasse une copie en RAM?
Probleme de la relocation du programme

> Car ça serait bien plus facile pour moi de tester.
Et 100x plus pratique aussi

>Que de à chaque fois, envoyer une ROM! (Je sais y a VTI mais bon tester sur Real TI c'est bien mieux des fois).
Y'a aussi tiemu

TIEmu qui s'est vraiment énormément amélioré depuis la 1.80a, mais dont la fiabilité de l'envoi de fichiers reste problématique...

>Sinon une petite question, est-il possible sous PedRom, d'executer un fichier en archive sans que PedRom fasse une copie en RAM?
Probleme de la relocation du programme

Lors de l'archivage, y a pas moyen de réaliser les relocations?
J'm'avance pas trop, j'y connais rien.

Il semble que dans PedroM-internal.h il manque la définition de INT_HANDLER.
Bon voici les derniers sources modifiées... Normalement y a plus de pb de chemin mais bon reste des pbs avec PedroM.
http://tisofts.free.fr/GFABasic/gfa_pedrom.zip

Lors de l'archivage, y a pas moyen de réaliser les relocations?

La mémoire archive peut subir un garbage collector(du moins sous AMS)..

Je sais mais faut être méthodique.
Genre une fonction de ce style:
ArchiveMalloc (x); dans ce cas on a un Garbage Collect ok, ça ne pose pas de pb mais rien est écrit dans l'Archive. Juste un pointeur est renvoyé.
Ensuite une fonction qui copie le programme en Archive et en même temps fait les relocations.

Après oui il peut y avoir un Garbage Collect mais on peut faire comme le tas, mettre un flag qui force à ne pas ordonner.

Les Flash Apps signées fonctionnent très bien en archive alors pourquoi on ne pourrait pas faire de même.

>TIEmu qui s'est vraiment énormément amélioré depuis la 1.80a, mais dont la fiabilité de l'envoi de fichiers reste problématique...
Il faut avoir un PC puissant pour envoyer les fichiers
Enfin perso je ne travaille plus qu'avec lui.

>Lors de l'archivage, y a pas moyen de réaliser les relocations?
>J'm'avance pas trop, j'y connais rien.
et les relocations RAMS

>Normalement y a plus de pb de chemin mais bon reste des pbs avec PedroM.
Normal, mais je suis la &)
Je regarderai ca Lundi. Le Week-end, c'est sacre.

>Les Flash Apps signées fonctionnent très bien en archive alors pourquoi on ne pourrait pas faire de même.
Parce que je veux pas une bouse comme ca dans PedroM. Ca sera bien mieux ou ne sera pas

PpHd :
>Les Flash Apps signées fonctionnent très bien en archive alors pourquoi on ne pourrait pas faire de même.
Parce que je veux pas une bouse comme ca dans PedroM. Ca sera bien mieux ou ne sera pas

D'un autre coté, ce serait bien d'avoir un moyen d'avoir des flashapps sous pedrom qui permette de linker avec du code non gpl... (ni GTC ni CC ne peuvent etre relicencés en GPL)

>D'un autre coté, ce serait bien d'avoir un moyen d'avoir des flashapps sous pedrom qui permette de linker avec du code non gpl...
Si tu veux m'aider a patcher GCC et le linker, je pourrais te donner les infos

J'oubliais qu'il faut aussi supporter les apps > 64K.

PpHd :
>D'un autre coté, ce serait bien d'avoir un moyen d'avoir des flashapps sous pedrom qui permette de linker avec du code non gpl...
Si tu veux m'aider a patcher GCC et le linker, je pourrais te donner les infos

quel rapport avec GCC

J'oubliais qu'il faut aussi supporter les apps > 64K.

tutafé ^^

Mais bon pour ma part j'aurais juste besoin d'un moyen d'envoyer un truc de 100 ko en ROM appelable a partir de la ligne de commande (quitte a ce que ca prenne 128 ko de ROM plutot que 100, a la limite on s'en fout pour le moment), avec simplement des relocations internes. Ca devrait etre faisable, non ? (ou alors ca s'explique par ta propre incompetence © ) Et si tu fais un format de fichier suffisamment extensible, ca ne devrait pas poser de pb pour rajouter des bells and whistles a la con