PedROM et GTC - Page 2

getchar, getc, gets

Autre possibilité : t'implémente ça pour PedroM. (sachant qu'il y a déjà fgetc)

PedroM fait tout le reste que tu as réimplémenté.

Lionel Debroux (./19) :

Je ne comprends pas qu'on ne puisse pas imposer à un compilateur de ne pas pondre de relogements.

Certaines des causes de relogements, ne citons que les tableaux de chaînes de caractères, tiennent à la sémantique du langage C

Tu peux préciser ce point ?

./22 Pas mal
Perso je trouve que la mise en œuvre est un peu laide pour être intégrée dans TIGCC/GCC4TI, mais c’est vrai qu’une telle couche (même très partielle) ne me semble pas totalement inutile…

irie officielle, au lieu de redéfinitions ultérieures. Cela s'intégrerait par un jeu de #ifdef COMPATIBILITE_PC ma définition #else définition originale de TIGCC #endifCa peut se délaidir considérablement si les modifications affectent directement la librapour chaque fonction réécrite. Le "flag" COMPATIBILITE_PC serait défini dans stdio.h par exemple, et la simple inclusion de ce header activerait toute la couche (y compris le "chargeur du main" et les manips qui l'accompagnent).


Folco : Il y a deux choses qui ont nécessité un vrai travail : le "chargeur du main" et la fonction générique _internal_getsn. Les autres fonctions sont des simples macros qui appellent la fonction générique avec les paramètres adéquats. Il doit aussi y avoir moyen de redéfinir scanf (elle doit pouvoir se décomposer en un _internal_getsn suivi d'un sscanf, si j'ai pas fumé).

Au fait, Kevin et Lionel, j'ai constaté deux problèmes en codant le bidule.

1) Lorsqu'on implémente une fonction qui s'appelle main :
- TIGCC émet un warning si elle retourne autre chose qu'un entier,
- tout appel à cette fonction plante le programme.
C'est pour cela que j'ai été obligé de bidouiller en demandant au préprocesseur de changer tous les main en m_a_i_n dans le code utilisateur.

2) push_shortint et ses soeurs ne semblent pas définies dans les headers (warning du compilateur lorsqu'on les utilise) alors qu'elles sont référencées dans la doc
J'ai donc copié le prototype de la doc dans mon .h


//

Question : A quoi sert ER_throwVar ? Je n'arrive pas à comprendre l'explication de la doc.

scanf est déjà défini par getsn et sscanf, et cela depuis pas mal de temps. Au départ, le scanf travaillait en direct, mais ça empêchait presque toute forme de correction et ça faisait que parfois ça parsait sans appuyer sur ENTER, parfois pas. Donc si tu redéfinis getsn, ça va automatiquement aussi porter sur scanf.

Thibaut (./36) :
2) push_shortint et ses soeurs ne semblent pas définies dans les headers (warning du compilateur lorsqu'on les utilise) alors qu'elles sont référencées dans la doc

Ton MIN_AMS est trop petit.

Question : A quoi sert ER_throwVar ? Je n'arrive pas à comprendre l'explication de la doc.

Renvoyer une erreur avec un code d'erreur variable à AMS. Voir aussi ENABLE_ERROR_RETURN dans la doc. (Si tu utilises ER_throwVar sans ça, tu risques plusieurs problèmes.) Et attention, ça quitte immédiatement le programme, sauf s'il y a des TRY qui interceptent l'erreur.

Certaines des causes de relogements, ne citons que les tableaux de chaînes de caractères, tiennent à la sémantique du langage C

Tu peux préciser ce point ?

Pour générer le binaire correspondant à
char * mystrings[] = {"foo", "bar", "baz"};
le compilo crée deux ensembles de données:
* les chaînes "foo\0", "bar\0" et "baz\0" elles-mêmes;
* le tableau des pointeurs qui référencent ces chaîne, de manière à permettre l'adressage direct (c'est ça qui nécessite un relogement par pointeur, pour pouvoir s'adapter à une adresse variable de chargement tout en ayant un pointeur direct):
strcpy(dest, mystrings[ 0 ]);

D'accord. Et comment peut-on exploiter le code d'erreur ? Ca affiche quelque chose ?

./38 Ça changerait quoi _sémantiquement_ de faire des lea mystrings(pc),a0 plutôt que movea.l mystrings, a0 ?

Rien, c'est ce que le compilateur fait déjà, les relogements, c'est à l'intérieur du tableau!

Ce code est compilé par TIGCC en:

	.globl	mystrings
	.section	.rodata.__unalignedstr,"dmu"
.LC0:
	.ascii "foo\0"
.LC1:
	.ascii "bar\0"
.LC2:
	.ascii "baz\0"
	.section	.data.mystrings,"d"
	.even
mystrings:
	.long	.LC0
	.long	.LC1
	.long	.LC2

(Pour les flags des sections: d = data, m = mergeable, u = unaligned.)

Ce sont les .long du tableau qui nécessitent les relogements.

Bon je vais rester sur le retour du code à Home. Je fais ce truc pour moi et ceux qui voudront pas s'embêter avec les bizarreries de la prog sur TIGCC. Libre à chacun de modifier la couche.

Est -ce qu'il est simple d'installer GCC4TI sur Ubuntu (IDE et complilateur) ? Ou peut-on avoir la dernière version ?

http://trac.godzil.net/gcc4ti est le site officiel, les téléchargement ce font la bas

./41 Ah oui j’étais à côté de la plaque.
Cependant on pourrait se démerder, par diverses bidouilleries, pour éliminer ces relogements (par exemple du code de démarrage qui initialise les champs du tableau, ou, pire, faire en sorte que ces pointeurs ne contiennent pas une adresse mémoire, mais un déplacement). La sémantique en serait vraiment modifiée ?

Sasume (./45) :
Cependant on pourrait se démerder, par diverses bidouilleries, pour éliminer ces relogements (par exemple du code de démarrage qui initialise les champs du tableau, ou, pire, faire en sorte que ces pointeurs ne contiennent pas une adresse mémoire, mais un déplacement). La sémantique en serait vraiment modifiée ?

Ya un moyen très propre qui prend en plus moins de mémoire : c'est la table de saut pc-relative... Je n'écris que ça dans mes programmes, ça marche au poil, je sais pas pourquoi un compilateur n'est pas capable de toujours faire ça.

Est-ce qu'il est simple d'installer GCC4TI sur Ubuntu (IDE et complilateur) ?

La compilation de l'environnement ligne de commande complet (hors IDE) a été testée sur Ubuntu 9.04, et Ubuntu 9.04 est un des *nix pour lesquels GCC4TI 0.96 Beta 10 est fourni sous forme binaire précompilée.
Pour l'IDE, télécharge et compile à la main KTIGCC 1.10, en ayant au préalable installé les assez nombreux packages "-dev" nécessaires à la compilation d'une appli KDE. Pour certains workflows, tu peux aussi utiliser l'IDE plus puissant de ton choix, et un système de build plus puissant et plus flexible que ne l'est le système TIGCC Project (TPR).

Ou peut-on avoir la dernière version ?

http://trac.godzil.net/gcc4ti pour GCC4TI.
Voir la signature de Kevin pour TIGCC.

Sasume (./45) :
par exemple du code de démarrage qui initialise les champs du tableau,

C'est du relogement, ça, tu ne peux pas faire ça si le tableau est en FlashROM.

La seule chose que la chaîne d'outils peut faire, c'est de créer les données à reloger dans une section BSS (section allouée en temps d'exécution) en RAM et de générer du code pour les initialiser (ou d'avoir une représentation avec relogements qui est ensuite utilisée par du code de démarrage tout prêt pour initialiser le tableau en RAM). Ce n'est pas vraiment évident à coder.

ou, pire, faire en sorte que ces pointeurs ne contiennent pas une adresse mémoire, mais un déplacement). La sémantique en serait vraiment modifiée ?

Bah oui, ce ne serait plus un tableau de pointeurs. Un tableau en C est quelque chose de bien précis (convertissable en un pointeur, accès aux membres par x[i] == *(x+i) == lire sizeof(*x) octets à (adresse de x) + i*sizeof(*x)), on ne peut pas le rendre "magique" de la manière que tu proposes.

Folco (./46) :
Ya un moyen très propre qui prend en plus moins de mémoire : c'est la table de saut pc-relative... Je n'écris que ça dans mes programmes, ça marche au poil, je sais pas pourquoi un compilateur n'est pas capable de toujours faire ça.

Parce qu'un tableau de pointeurs en C doit être un tableau qui contient des pointeurs, pas des informations permettant de calculer les pointeurs, cf. ci-dessus.