Punkoe - Page 2

Sasume
: Pour le saut, quelle touche est la plus pratique sur TI-92+ ? Et sur la V200 ? (ça m'arrange si c'est une de celles-ci : Hand, Shift, Diamnd, 2nd)

[HAND] est faisable pour les 2.
Sur la TI-92+, [F1] serait peut-être plus pratique.

Sinon, quelques questions : quand on invoque TIGCC avec plusieurs fichiers sources, comment les transmet-il au linker ?

Il les compile/assemble en des fichiers objet qui sont passés au linker.

Comment le linker sait-il quel fichier objet il doit mettre en premier (parce que s'il ne met pas celui où il y a le main, ce n'est pas pratique).

Même si _main n'est pas en premier, avec TIGCC 0.95, ça marche sans problèmes.

Je suppose qu'il les met dans l'ordre où on les lui passe sur la ligne de commande.

Oui.

Avec le nouveau linker, comment savoir dans quelle section je dois mettre mon code ou mes données ? Quelles sont les sections qui existent ?

En principe:
.text -> code
.data -> données
.bss -> données non-initialisées ou initialisées à 0 selon les options
En pratique, tu peux mettre tout dans .text si ça t'arrange. L'intérêt de .data est de permettre les fichiers de données externes. Mais pour cela, il faut aussi que tous les accès de .text vers .data soient absolus. Les accès vers .bss doivent aussi être nécessairement absolus. Mais le linker peut les optimiser en accès PC-relatifs si les sections sont réunies en temps de linking (en fonction des options choisies) et si la distance est suffisamment petite. Autre limitation: les sections .data (dans le cas d'une variable de données externe) et .bss ne peuvent pas contenir des relogements, donc si tu as des trucs de style: foo: .long bar (où bar est un label), il faut les mettre dans .text.

L'optimisation cut-ranges permet de gagner de la place sur les instructions qui ont été racourcies par a68k lors de l'assemblage, c'est bien ça ?

Non, sur les instructions qui ont été raccourcies par ld-tigcc lors du linking. A68k fait ça tout seul quand il raccourcit des instructions.

Quad je compile avec cette option, je gagne 4 octets. Cela veut dire que j'ai écrit quelque part une instruction qui a pu être remplacée par une autre plus petite, comment retrouver cet endroit dans mes sources ?

Mauvaise question. La bonne question est: Suis-je censé faire ce remplacement moi-même? Et la réponse est non. L'optimisation du linker sert justement à transformer des références absolues en PC-relatives là où on connait la distance seulement en temps de linking!

Mais si tu veux quand-même le savoir, compile la version autonome de ld-tigcc, utilise ld-tigcc --dump et examine les dumps. (C'est ce que je faisais toujours pour déboguer le linker.)

Kevin Kofler
:

Sasume
: Pour le saut, quelle touche est la plus pratique sur TI-92+ ? Et sur la V200 ? (ça m'arrange si c'est une de celles-ci : Hand, Shift, Diamnd, 2nd)

[HAND] est faisable pour les 2. Sur la TI-92+, [F1] serait peut-être plus pratique.

Je pense utiliser [HAND] pour des raisons de simplicité (Mac> elle désigne la même touche que lock, non ?), plutôt que [F1].

Au fait, pour le support des différents modèles, vous préférez unn programme compatible on-calc mais un peu plus gros ou bien des programmes différents selon les modèles ?

Comment le linker sait-il quel fichier objet il doit mettre en premier (parce que s'il ne met pas celui où il y a le main, ce n'est pas pratique).

Même si _main n'est pas en premier, avec TIGCC 0.95, ça marche sans problèmes.

J'ai dit main, mais je pensais "début du programme".
En fait, la réponse à ma question se trouvait dans ta réponse suivante. Merci.

En ce qui concerne les sections, où va mon code lorsque je ne précise rien ?

Quand je compile avec cette option, je gagne 4 octets. Cela veut dire que j'ai écrit quelque part une instruction qui a pu être remplacée par une autre plus petite, comment retrouver cet endroit dans mes sources ?

Mauvaise question. La bonne question est: Suis-je censé faire ce remplacement moi-même? Et la réponse est non. L'optimisation du linker sert justement à transformer des références absolues en PC-relatives là où on connait la distance seulement en temps de linking!

Cette optimisation (cut-ranges) permet de remplacer quelles instructions précisément ? Si c'est du remplaçage "adressage absolu" par "adressage PC-relatif", ça ne me sert à rien puisque je n'utilise aucune adresse absolue pour accéder à mes données.
En fait, je voulais savoir à quel endroit l'instruction est changée parce que j'essaie de faire attention quand je code à utiliser le plus possible l'instruction la plus petite pour faire ce que je veux faire (par ex : addq au lieu de add quand c'est possible).
Or si le linker trouve quelque chose à optimiser, c'est que je n'ai pas bien fait mon boulot, donc je veux savoir où je me suis trompé.
Je sais que ce sont plutôt des optimisations qui se font en temps d'assemblage par a68k, mais comme j'ai remarqué que votre linker fait parfois des trucs qui devraient être fait en temps d'assemblage, j'ai pensé que c'était peut-être le cas ici.
Mais peut-être que non, auquel cas ce n'est pas la peine que j'essaie de relire mon code pour trouver mon erreur.

hand==lock, oui

J'ai l'impression que quand on veut lacher la barre au moment où elle est remplie au maximum, ça ne saute pas, comme si il y avait un décalage entre ce qui est affiché et la puissance réelle du saut. Je me trompe ?

Sasume
: (Mac> elle désigne la même touche que lock, non ?)

Oui.

Au fait, pour le support des différents modèles, vous préférez unn programme compatible on-calc mais un peu plus gros ou bien des programmes différents selon les modèles ?

Personnellement, je choisis toujours la première solution.

Même si _main n'est pas en premier, avec TIGCC 0.95, ça marche sans problèmes.

J'ai dit main, mais je pensais "début du programme".

Normalement, le début du programme (__ld_entry_point) se trouve dans le code de démarrage. Mais je vois que d'après tes sources, tu fais du _nostub pur à la bonne vieille manière. Pourtant, avec le code de démarrage, c'est tellement plus pratique... (Et oui, il faudra que je mettre un ou deux chapître(s) sur le mode tigcc_native, les global imports et le code de démarrage dans mon tuto...)

En ce qui concerne les sections, où va mon code lorsque je ne précise rien ?

.text

Mauvaise question. La bonne question est: Suis-je censé faire ce remplacement moi-même? Et la réponse est non. L'optimisation du linker sert justement à transformer des références absolues en PC-relatives là où on connait la distance seulement en temps de linking!

Cette optimisation (cut-ranges) permet de remplacer quelles instructions précisément ? Si c'est du remplaçage "adressage absolu" par "adressage PC-relatif", ça ne me sert à rien puisque je n'utilise aucune adresse absolue pour accéder à mes données.

Ben si, elle te fait gagner 4 octets.

D'ailleurs, --cut-ranges ne fait que nettoyer là où les autres optimisations ont permis de gagner de la place, c'est --optimize-code qui fait les optimisations elles-mêmes.

Ce que ça fait:
* absolu -> PC-relatif dans toutes les instructions qui le permettent
* bxx.w -> bxx.s
* optimisation tailcall (--optimize-returns): jsr+rts=jmp, bsr+rts=bra

En fait, je voulais savoir à quel endroit l'instruction est changée parce que j'essaie de faire attention quand je code à utiliser le plus possible l'instruction la plus petite pour faire ce que je veux faire (par ex : addq au lieu de add quand c'est possible). Or si le linker trouve quelque chose à optimiser, c'est que je n'ai pas bien fait mon boulot, donc je veux savoir où je me suis trompé.

Pas forcément. Si tu as un saut d'un fichier source/objet à un autre, tu ne peux a priori pas savoir si un bra.s sera suffisant (ni si un bra.w sera suffisant, mais ça, tu as déjà dit que tu le présupposais). Il vaut mieux ne faire aucune présupposition et laisser que le linker fasse le boulot. C'est d'ailleurs aussi valable pour les bra.w et les références PC-relatives.

Je sais que ce sont plutôt des optimisations qui se font en temps d'assemblage par a68k, mais comme j'ai remarqué que votre linker fait parfois des trucs qui devraient être fait en temps d'assemblage, j'ai pensé que c'était peut-être le cas ici.

Ce que le linker fait ne sont en général pas "des trucs qui devraient être fait en temps d'assemblage", mais des trucs qui peuvent être faits en temps d'assemblage seulement pour les programmes à un seul fichier objet. Avec plusieurs fichiers objet, les distances ne sont pas connues lors de l'assemblage et donc l'assembleur présuppose le pire cas et le linker optimise.

Mais peut-être que non, auquel cas ce n'est pas la peine que j'essaie de relire mon code pour trouver mon erreur.

Cf. ci-dessus.
Mais peut quand-même être intéressant de savoir ce qui est optimisé... Je vais jeter un coup d'œil sur les dumps pour toi.

Bug report:

; adresses utiles
AI1 equ $40064
AI5 equ $40074

C'est incompatible avec la TI-89 Titanium, ça.

Voilà:

Dans punkoe.o:

     0x000078: 42 93 42 AB 00 04 61 00
     0x000080: <2B: Afficher (->) (rel)>
     0x000082: 61 00
     0x000084: <2B: GestionBarreSaut (->) (rel)>
     0x000086: 61 00
     0x000088: <2B: GestionPerso (->) (rel)>
     0x00008A: 61 00
     0x00008C: <2B: GestionCamera (->) (rel)>
     0x00008E: 61 00
     0x000090: <2B: Afficher (->) (rel)>

est optimisé en:

     0x000078: 42 93 42 AB 00 04 61
     0x00007F: <1B: Afficher (rel) - 1>
     0x000080: 61 00
     0x000082: <2B: GestionBarreSaut (rel)>
     0x000084: 61 00
     0x000086: <2B: GestionPerso (rel)>
     0x000088: 61 00
     0x00008A: <2B: GestionCamera (rel)>
     0x00008C: 61
     0x00008D: <1B: Afficher (rel) - 1>

Dans le code source, ça correspond à:
Dans punkoe.asm:

  bsr     Afficher

\MainLoop:

  bsr     GestionBarreSaut

  bsr     GestionPerso

  bsr     GestionCamera

  bsr     Afficher

est optimisé en:

  bsr.s   Afficher

\MainLoop:

  bsr     GestionBarreSaut

  bsr     GestionPerso

  bsr     GestionCamera

  bsr.s   Afficher

Vertyos
: J'ai l'impression que quand on veut lacher la barre au moment où elle est remplie au maximum, ça ne saute pas, comme si il y avait un décalage entre ce qui est affiché et la puissance réelle du saut. Je me trompe ?

J'ai essayé de faire bien attention, normalement.
augmenter la barre de 1

Mon code se résume à ça :si l'utilisateur relâche [2nd]
  déclencher l'évènement SAUT
sinon si le remplissage du au passage précédent est >= 32
  réinitialiser la barre
sinon si le temps écoulé depuis la dernière augmentation est suffisant

Mais j'avoue que c'est actuellement difficile de faire un saut avec la barre pleine (à 32) parce qu'avant d'augmenter la valeur de la barre de 1, je vérifie qu'il se soit écoulé un certain temps, ce que je ne fais pas avant de vérifier qu'elle est au max, ce qui signifie qu'on a un temps extrêmement court pour relâcher [2nd]. Je changerai ça pour la prochaine version.
Si tu veux le faire toi-même, il te suffit de prendre les lignes 31 et 32 du fichier barre.asm et de les insérer etre les lignes 35 et 36 et recompiler avec le batch.

Kevin Kofler
:

Sasume
: Au fait, pour le support des différents modèles, vous préférez unn programme compatible on-calc mais un peu plus gros ou bien des programmes différents selon les modèles ?

Personnellement, je choisis toujours la première solution.

Je ferai pareil alors

Normalement, le début du programme (__ld_entry_point) se trouve dans le code de démarrage. Mais je vois que d'après tes sources, tu fais du _nostub pur à la bonne vieille manière. Pourtant, avec le code de démarrage, c'est tellement plus pratique... (Et oui, il faudra que je mettre un ou deux chapître(s) sur le mode tigcc_native, les global imports et le code de démarrage dans mon tuto...)

Oui, j'avais regardé un peu la doc avant de mettre mon xdef _nostub, mais j'ai cru comprendre qu'il faut spécifier au moins une section de startup-code, mais je ne sais pas à quoi correspondent les sections possibles puisque leurs noms sont _st1, _st2, _st3, ...
Donc pour l'instant, je reste en _nostub.

Mais peut quand-même être intéressant de savoir ce qui est optimisé... Je vais jeter un coup d'œil sur les dumps pour toi.

Merci, je ne t'en demandais pas tant.
Après la lecture de ton report, effectivement, il s'agit d'une optimisation qui doit être faite en temps de linking, donc je ne vais pas modifier mon code pour écrire des bsr.s à la place des bsr.w qui ont été optimisés. Parce que par exemple, si je linke mes fichier .asm dans un ordre différent de l'ordre actuel et que je mets le fichier affichage.asm vers la fin, l'instruction bsr.s ne permettra probablement pas de stocker la valeur du déplacement.

Kevin Kofler :
Bug report:

; adresses utiles
AI1 equ $40064
AI5 equ $40074

C'est incompatible avec la TI-89 Titanium, ça.

Oui, je sais, mais je l'ai précisé dans le README, donc ce n'est pas un "bug" (et tu le sais très bien).
D'ailleurs, vu que je prévois de supporter la titanium plus tard, la méthode à l'ancienne qui consiste à toucher aux ports pour désactiver la protection de la mémoire basse (c'est bien $600001 d'ailleurs ?), elle fonctionne toujours sur titanium, elle ?

Sasume
:

Normalement, le début du programme (__ld_entry_point) se trouve dans le code de démarrage. Mais je vois que d'après tes sources, tu fais du _nostub pur à la bonne vieille manière. Pourtant, avec le code de démarrage, c'est tellement plus pratique... (Et oui, il faudra que je mettre un ou deux chapître(s) sur le mode tigcc_native, les global imports et le code de démarrage dans mon tuto...)

Oui, j'avais regardé un peu la doc avant de mettre mon xdef _nostub, mais j'ai cru comprendre qu'il faut spécifier au moins une section de startup-code, mais je ne sais pas à quoi correspondent les sections possibles puisque leurs noms sont _st1, _st2, _st3, ... Donc pour l'instant, je reste en _nostub.

Tu n'es pas obligé de définir ta propre section de démarrage, tu peux aussi en importer une avec un global import.

L'entête d'un programme tigcc-native minimal (strictement équivalent au _nostub classique, le saut du code de démarrage vers __main sera supprimé par les optimisations du linker parce que c'est un bra à l'instruction d'après) est

_tigcc_native: xdef _tigcc_native
__ref_all___startup_code: xdef __ref_all___startup_code
__ref_all___nostub: xdef __ref_all___nostub
 xdef __main

__main:

(C'est __main et pas _main parce qu'en mode kernel, le code de démarrage utilise _main à ses propres fins.)

Tu peux aussi rajouter d'autres trucs, par exemple __ref_all___save_screen pour ne pas avoir à t'occuper de ça toi-même. Et ça te permet aussi d'utiliser les importations automatiques, par exemple pour les relogements en les formats personnalisés (par exemple le format des kernels, mais sans kernel ), les sections BSS (utilisables comme en mode kernel, mais sans kernel ) etc.

Mais peut quand-même être intéressant de savoir ce qui est optimisé... Je vais jeter un coup d'œil sur les dumps pour toi.

Merci, je ne t'en demandais pas tant. Après la lecture de ton report, effectivement, il s'agit d'une optimisation qui doit être faite en temps de linking, donc je ne vais pas modifier mon code pour écrire des bsr.s à la place des bsr.w qui ont été optimisés. Parce que par exemple, si je linke mes fichier .asm dans un ordre différent de l'ordre actuel et que je mets le fichier affichage.asm vers la fin, l'instruction bsr.s ne permettra probablement pas de stocker la valeur du déplacement.

Voilà, c'est ça. Donc tu as bien compris l'intérêt des optimisations du linker maintenant.

Kevin Kofler :
Bug report:

; adresses utiles
AI1 equ $40064
AI5 equ $40074

C'est incompatible avec la TI-89 Titanium, ça.

Oui, je sais, mais je l'ai précisé dans le README, donc ce n'est pas un "bug" (et tu le sais très bien).

Oups... Ça m'apprendra à lire le README avant de reporter un bogue... Désolé...

D'ailleurs, vu que je prévois de supporter la titanium plus tard, la méthode à l'ancienne qui consiste à toucher aux ports pour désactiver la protection de la mémoire basse (c'est bien $600001 d'ailleurs ?),

Oui.

elle fonctionne toujours sur titanium, elle ?

Oui.

Kevin Kofler :
Tu peux aussi rajouter d'autres trucs, par exemple __ref_all___save_screen pour ne pas avoir à t'occuper de ça toi-même.

Ben j'efface l'écran en même temps que je le sauve, donc ça va me prendre de la place en plus si je le sauve avec _save_screen et qu'après, je refais une boucle pour l'effacer.

Finalement, je n'ai pas vraiment compris à quoi cela me servirait d'utiliser le mode _tigcc_native

Sasume
: Si tu veux le faire toi-même,

Non

C'est pour te permettre de jouer sans avoir à attendre la prochaine release.
Enfin, pour un détail de ce peu d'importance, je comprends...
De toute façon, ce que je t'avais dit n'était pas tout à fait correct

Sinon, pour les modèles de TI à grand écran, l'utilisation de la touche [F1] ne me pose aucun problème finalement, donc est-ce que c'est bien aussi pour les V200 d'utiliser F1 ?

Bon, le support des TI-92+ et V200 a été fait (pour télécharger la nouvelle version : Punkoe.zip).

Je n'ai pas pu tester pour les V200, donc c'est possible qu'il y ait des problèmes.
énérer le fichier .v2z, je suis obligé de faire _v200: xdef _v200Par ailleurs, pour gAlors que pour spécifier les cibles _ti89 et _ti92plus, je n'ai pas besoin de déclarer le symbole dans mon fichier source.
Pourquoi ?

Pour V200, il me semble que lock est plus pratique (vu que les touches Fx sont sous l'écran).

Pour la version 92+, est-ce que tu pourrait rajouté un cdre, c pas évident de différencié le bord de la fin d'un ligne.

Pour lock, c parfait.

Sinon le petit détail pour effectué les grand sauts quand la barre est vide, ça me dérange pas de le modifié moi-même en attandant la release

Normalement je l'ai déjà changé dans cette nouvelle version.
Pour le cadre, par contre, c'est un peu pète couille. Mais c'est vrai, j'ai remarqué en testant, que ce n'est pas pratique souvent on ne sait pas où sont les bords. Donc peut-être que je changerai ça quand même un jour.

Sasume
:

Kevin Kofler :
Tu peux aussi rajouter d'autres trucs, par exemple __ref_all___save_screen pour ne pas avoir à t'occuper de ça toi-même.

Ben j'efface l'écran en même temps que je le sauve, donc ça va me prendre de la place en plus si je le sauve avec _save_screen et qu'après, je refais une boucle pour l'effacer.

Pour effacer l'écran, il y a ScreenClear...

Finalement, je n'ai pas vraiment compris à quoi cela me servirait d'utiliser le mode _tigcc_native

À profiter au maximum du linker de TIGCC 0.95. Mais tu n'y es nullement obligé!

Sasume
: Sinon, pour les modèles de TI à grand écran, l'utilisation de la touche [F1] ne me pose aucun problème finalement, donc est-ce que c'est bien aussi pour les V200 d'utiliser F1 ?

Pas vraiment. Sur la V200, c'est [F1] qui est plus à l'intérieur que [HAND].

Sasume :
énérer le fichier .v2z, je suis obligé de faire _v200: xdef _v200Par ailleurs, pour gAlors que pour spécifier les cibles _ti89 et _ti92plus, je n'ai pas besoin de déclarer le symbole dans mon fichier source. Pourquoi ?

Parce que _v200 n'est pas défini dans OS.h.
D'ailleurs, si tu utilisais l'assembleur GNU au lieu de l'assembleur A68k que nous ne livrons plus que pour des raisons de compatibilité antérieure, tu n'aurais pas ce problème (il permet d'exporter un symbole sans le définir en label).

Sasume :
Normalement je l'ai déjà changé dans cette nouvelle version.

erf... heureusement que tu le dis, j'imagines même pas ce que ça devait être avant

Meuh non
Bon, sinon, je pense pouvoir faire quelque chose pour les contours de l'aire de jeu

cool^^

Mmh, finalement, ce sera pour une autre fois
Voici une nouvelle version qui gère le high score : Punkoe.zip
En outre, le programme devrait être compatible avec la TI-89 Titanium (je vais demander à qq1 de tester).
Je vais faire un autre topic dans une section plus fréquentée de yN, cette version est proche de la version finale, je voudrais qu'elle soit testée.

y a pas un bug de yN dans le ./2 ?

oué, si t'as FireFox (puces dans la marge ?)

oué

Et maintenant, c'est mieux ?

je crois vu que je vois rien de particulié^^

Oui.