GTC 0.90 - Page 5

Folco : Ben si, mais du coup "c'est [pas] qu'une ligne un trampoline" écrit en C
compilateur vire tout ce qui est inutile (création de l'espace de mémoire local, sauvegarde de registres, et que sais-je) et que la fonction qui en appelle une autre se résume à un trampoline: jsr offset(pc)Cela dit, peut être que le

Le code que j'ai proposé correspond à peu près à ce que pondrait un compilateur si on faisait un trampoline pour chaque fonction. Pas besoin de modifier l'offset, il est calculé à la compilation (au linking si on veut chipoter).

Est-ce que ce que tu proposes est possible en C (sans déclencher une sauvegarde de registres par le compilo) ?

TI y arrive bien a faire des applications en C pour les app flash...

pourquoi les relogements se feraient pas à l'installation de la flashapp?

La mémoire flash n'a pas de GC?

les flashapps sont déplaçables?

en fait il suffit que ce GC soit aware des relogements.

squalyl -> ça me ferait chier que ce soit implémenté un truc comme ça

squalyl (./126) :
pourquoi les relogements se feraient pas à l'installation de la flashapp?

Il me semble que c'est le cas, en effet

Godzil (./125) :
TI y arrive bien a faire des applications en C pour les app flash...

Bah oui le format FlashApps de TI permet les relogements. Tu n'as pas suivi !

Folco_ (./124) :
Non ça marche pas, parce que ton offset est codé sur deux octets, donc tu peux pas sauter plus loin que 23 ko donc ça ne résoud pas le problème.

Mais TIGCC ne fait pas ce que tu dis automatiquement quand on appelle une fonction située à plus de 32 ko ?

Quand on appelle une fonction située à plus de 32 KB, TIGCC (et GTC, certainement ^^) créent une référence xxx.l relogée. Si c'est un programme ne s'exécutant pas à une adresse fixe, les données permettant la relocation restent dans l'image binaire de l'exécutable. Dans le cas d'un Flash OS, la référence est relogée à la fin du link, et l'image binaire du Flash OS ne contient pas de données permettant la relocation.

Thibaut (./121) :

trampoline:
jsr offset(pc)

Folco_ (./122) :
Pitêt. Mais là, tu perds l'intérêt du truc parce que pour marcher comme on veux, ton offset devra être modifiable (smc), alors qu'il vaut mieux passer par un registre :
jsr constant(pc,dn)

Ben non, ce qu'il faut c'est que les trampolines soient en RAM et qu'ils contiennent un jsr offset.l... Sinon comme on est limité à une amplitude de 32k il faudrait réserver 2 registres pour ça (et à ce moment-là autant ne pas utiliser de trampolines du tout).

Flanker (./130) :

squalyl (./126) :
pourquoi les relogements se feraient pas à l'installation de la flashapp?

Il me semble que c'est le cas, en effet

Ca se fait même à chaque reset, pour pouvoir gérer les relogements vers la RAM... GTC n'a pas besoin de ça, donc ça devrait être beaucoup plus simple à implémenter.

Et la garbage-collection n'est même pas indispensable : au pire il y a un ou deux secteurs de perdus, c'est moins dramatique que de ne pas pouvoir utiliser de Flashapps du tout.

Bah, il suffit de mettre un jmp 0(%pc,%d2.l) dans le trampoline, ensuite on limite les regparm à 2 maximum et on appelle les fonctions par move.l #target-trampoline,%d2; bsr trampoline.

Ou en fait on peut se passer carrément du trampoline:
move.l #target-(.+6),%d2; jsr 0(%pc,%d2.l)

Et sinon, il y a aussi les F-Line Jumps. Pour un jsr:
.word 0xfff0; .long target-.
C'est géré par PedroM et par AMS >= 2.04.

Les F-Line jumps sont la solution la plus petite (pas de relocation), mais probablement la moins efficace (même si elle libère deux registres: le déclenchement de l'exception F-Line et le RTE ajoutent des dizaines de clocks par invocation. Même si dans les handlers, FFF0, FFF1 et FFF2 sont des chemins de code plus courts que ceux des ROM_CALLs.

D'un autre côté, GTC compilant TIChess avec un temps dans les ordre de grandeur des 1~2 secondes, je sais pas si les sauts entre deux partie bien distinctes (donc peu fréquents si la structure du programme est pensée en conséquence) ferait de ce compilo on-calc un escargot. Déjà parce qu'on code pas souvent un projet de la taille de TIChess on-calc, ensuite parce qu'on reprochera jamais à un compilo on-calc de mettre 3 secondes au lieu de deux pour compiler un tel programme

Es-tu sûr que les 1-2 secondes, c'est on-calc et pas sur PC?

Meme avec une calc overclockée je serait tenté de dire qu'il s'agit des temps PC là ^^

Oué bon bref, peut-être, mais en tout cas mon souvenir est que c'est largement suffisant pour du code on-calc

Thibaut, t'as encore tes comparatifs ?

Vi, va voir dans la partie C

A propos de comparatifs: maintenant que GTC est publiquement accessible légalement, il serait peut-être temps qu'on se mette collectivement à faire un comparatif plus représentatif que le comparatif de Thibaut, qui était un peu trop petit ?
1) Détermination des applications
2) Exécution.

Pour ça, il faudrait que les programmes compilent, ce qui n'est pas le cas pour la plupart (ASM inline, floats etc.).

floats: mauvais exemple. Les floats d'AMS sont tellement lents que rares sont les jeux (ben oui, la majorité d'une liste représentative de programmes risquent quand même d'être composée de jeux, vu qu'il y a bien moins de programmes de maths C/ASM que de jeux C/ASM...) qui utilisent les floats. Et il n'y a virtuellement aucun programme qui utilise des floats binaires: il y a une vieille lib kernel avec une calling convention bizarre, les éventuels programmes l'utilisant ne tournent peut-être même pas sur les machines modernes.

ASM inline: bon exemple. Mais pour la même raison que les options de build optimisées et l'optimisation du code lui-même, dont je parlais ce matin dans le topic où tu écris explicitement vouloir détourner les gens de GTC ( http://tichessteamhq.yuku.com/topic/4646 ), l'ASM inline est plutôt rare.
Et je te rappelle qu'une partie de l'ASM inline de TI-Chess est des one-liners asm volatile pour tenter, sans grand succès d'ailleurs, de dé-pessimizer le code que GCC 4.x génère.

./142 ...

(edit -> ah oué vaut mieux être aveugle que de voir ce qu'on peut lire sur TICTHQ...)

Merde je pensais que le bébé Kevin avait grandi depuis le temps. ASM : c'est un non sens, puisqu'on compare les qualités de génération des compilateurs. En plus, presque aucun programmeur utilise l'inline. Float : mêmes remarques.

Trouve des programmes à mettre dans le test alors

Le code de PedroM est sous GPL, donc si quelqu'un veut l'implanter qu'il ne se gène pas.
Pour info, le plus dur ce n'est du tout le format, ni lerelocage, ni le GC, mais le transfert de la dite application.
Perso, cela ne m'interresse plus du tout (c'est en very low priority), donc si vous le voulez, faites-le.

L'ASM inline n'est pas du non-sens, on en trouve dans plein de programmes réels, surtout sur TI! Quant aux floats, on en trouve dans Gosper89 et d'autres programmes de Mathématiques ou sciences, dans certains jeux etc.

En gros, les programmes qui ont besoin de vitesse contiennent de l'ASM inline, les autres contiennent des floats.

./144: c'est clair que ça fait bizarre de lire des énormités du genre

I'll be willing to work with you the day you'll accept that I am the TIGCC project leader, period.

Comme si on, et en particulier myself, n'avait pas compris qu'il était le dictateur du projet TIGCC ??!

Merde je pensais que le bébé Kevin avait grandi depuis le temps.

So far, tous ceux qui ont eu cet espoir ont été déçus...

Vous n'avez même pas les couilles de répondre sur le forum d'où vos citations sont issues.