Grib - Page 2

Je regarderai ça. Pour ce dont j'aurais besoin pour ne pas passer du temps à modifier le tilemap engine d'ExtGraph et à pessimizer la calling convention, l'allocation inconditionnelle des planes consécutifs me suffirait. En plus, ça rend la routine plus petite.

Kevin va supprimer purement et simplement la détection de VTI de la routine de grays de TIGCCLIB quand TIEmu 2.00 release sera sorti, car TIEmu est indétectable. Du coup, la moitié des ~20 octets d'optimisation dont je lui avais parlé (qui a dit qu'il était bon en optimisation ?) s'en vont (le reste est l'optimisation des ROM_CALLs - ça fait un moment qu'il la maintient, mais il n'a même pas été foutu de voir ça, qui saute pourtant aux yeux dès qu'on lit la routine, si on a l'habitude de lire les ROM_CALLs classiques). La routine de grays de TIGCCLIB sera donc bientôt au moins une quarantaine d'octets plus petite qu'elle ne l'est actuellement.

Forker la routine de grays est assez facile. Aucune chance que les gens restent à des versions antérieures de TIGCC...

Même si TIEmu est mieux que VTI presque sur toute la ligne, on ne peut pas s'empêcher de penser qu'il a une arrière-pensée de rendre son propre boulot indispensable.

Même si TIEmu est mieux que VTI presque sur toute la ligne, on ne peut pas s'empêcher de penser qu'il a une arrière-pensée de rendre son propre boulot indispensable.

sûrement
un peu comme son habitude de toucher à tous les programmes GPL pour y faire 2 - 3 modifs et y mettre son nom ...

C'est sûr que si tu ne programmes qu'en ASM, le compilo amélioré (enfin, ça dépend en quoi - GCC 4.0 est un mélange de bon et de mauvais) ne va pas trop t'intéresser. En revanche, il peut toujours y avoir la doc de fonctions intéressantes, plus de choses dans TIGCCLIB.
Les outils que PpHd distribue sont un bon ton en-dessous de celui de TIGCC... Il n'y a pas deux optimizing linkers pour TIGCC.

Lionel Debroux
: Même si TIEmu est mieux que VTI presque sur toute la ligne

C'est malheureusement ce "presque" qui fait que certains (dont je fais partie) comptent garder VTI (GTK...). Mais ce n'est pas le sujet.

Cross avec #34.
Flanker, tu es méchant. Si tu lisais la mailing list de TIEmu, tu saurais qu'il est très loin de ne faire que deux ou trois modifs sur TIEmu, même en-dehors de la tiemu-tigcc-debugging branch. C'est un des gros beta-testeurs depuis un moment (les autres comprennant ExtendeD, PpHd, myself). C'est quand même largement grâce à lui que TIEmu, même en-dehors de la tiemu-tigcc-debugging branch, en est arrivé où il en est !

Tiens, depuis quand se préoccupe-t-il du goût des utilisateurs ?
Il a fallu que Sebastian et moi râlions lourdement pour qu'il accepte de baisser les settings d'optimisation vitesse extrémiste de -O3, et de faire -O4 pour ça. Il a fait perdre à tout le monde, lui compris, plus de temps qu'il ne lui en fallait pour le faire sans faire *****...
A part ça, pas de support de plusieurs pstarters (1 optimisé vitesse, 1 optimisé taille). Même si on lui faisait le code, je ne pense pas qu'il l'intégrerait. Ca a probablement du bon quand même: quoi qu'il en dise, pstarters suck, car ça gaspille de la place par rapport à un ttstart (générique) dès qu'il y en a plus d'un, donc ça augmente peut-être le taux d'utilisation de ttstart - qui lui, laisse le choix aux utilisateurs.

Lionel > je ne parlais pas que de TiEmu. Par exemple Venus (de Bob) il a juste modifié les menus pour pouvoir le disrtibuer ...

enfin bon, je ne suis pas complètement sûr que tout ça soit dans le sujet, donc il faudrait peut-être le recentrer, non ? (mais comptez pas trop sur moi, j'y connais rien en libs graphiques )

Du reste, voir les résultats du sondage qu'il a posté sur TI-Gen...

J'ai aussi modifié Venus, pour optimiser.

Cross.
C'est vrai.

En regardant le code de gray.s plus en détail, je m'aperçois qu'il y a encore plus de boulot que ce que j'ai cité plus haut...

> Flanker :
> un peu comme son habitude de toucher à tous les programmes GPL pour y faire 2 - 3 modifs et y mettre son nom ...
Je ne pense pas qu'il ait envie de mettre son nom. À mon avis, il a sa conception de ce qui est bien et il dépense beaucoup d'énergie pour que les choses y ressemblent. Donc quand les progs sont open source, il en profite pour corriger ce qui ne va pas selon lui, pour que ça corresponde à ce qu'il pense qui est bien (_nostub, menus standards, compatibilité TIGCCLIB, etc...). Mais mettre son nom dans la liste des auteurs n'est pas sa principale motivation à mon avis.
Par exemple, il ne supportait pas que mon tilemap engine ne permette pas d'utiliser le double buffering de tigcclib, donc il a modifié le tilemap engine pour que ce soit le cas. Moi perso je trouve que c'est bien de laisser le choix à l'utilisateur, plutôt que d'essayer d'imposer sa conception du bien, donc j'ai écrit grib pour permettre d'allouer soi-même les plans des niveaux de gris (et donc permettre d'allouer des plans consécutifs compatibles avec le tilemap engine) ; ce qui fait que les utilisateurs peuvent choisir TIGCCLIB + fork de kevin ou grib + tilemap engine, selon leur envie.

> Vertyos :
> C'est malheureusement ce "presque" qui fait que certains (dont je fais partie) comptent garder VTI (GTK...).
Franchement, je trouve TiEmu aussi bien que vti, les petits inconvénients c'est qu'on ne peut pas faire drag and drop pour envoyer des fichiers (mais c'est pas très gênant...), TIGCC ne permet pas d'envoyer le programme qui vient d'être compilé dessus et on ne peut pas prendre de screenshot animé avec tishot.

Il y aurait une troisième option: fork de TIGCCLIB (puisqu'il ne veut vraiment pas inclure une nouvelle routine ou modifier l'ancienne pour toujours utiliser deux planes consécutifs alloués ailleurs, même sur HW1; même en lui expliquant bien pourquoi ça n'a pas d'importance, car les programmes doivent être faits pour les HW2 qui ont au plus autant de mémoire que les HW1, ça ne passe pas) + tilemap engine as is.

> c'est qu'on ne peut pas faire drag and drop pour envoyer des fichiers
Ah bon, VTI supporte le drag&drop ?
> TIGCC ne permet pas d'envoyer le programme qui vient d'être compilé dessus
Ca m'étonnerait bien que ça dure...
> on ne peut pas prendre de screenshot animé avec tishot.
Et CalcCapture ?

enfin meme en supposant que Ti-Emu soit en tout point supérieur a VTI, ce serait qd meme débile de faire des progs qui ne marchent pas sous VTI, ne serait-ce parce que plein de monde l'utilise encore... (d'ailleurs il ne demande pas une lib graphique d'une dizaine de Mo, et n'a par rapport a Ti-Emu aucun inconvénient pour qqun qui ne développe pas)

oué, mais ça, ça fait une semaine qu'on lui dit tous les soirs, à Kevin...

> Et CalcCapture ?
Ça marche

Eh oui...

Pour info, je viens de gagner 42 octets sur la routine de TIGCCLIB, sans supprimer la détection de VTI, ni passer en 2 planes consécutifs de façon inconditionnelle...
Pas testé, en revanche. Entre TIEmu (HW1, HW2/3) et VTI (HW1-VTI), je devrais arriver à enlever les bugs les plus évidents avant d'uploader le tout.

Cross.
C'est bien que CalcCapture fonctionne.

Ben non, sur VTI, Address Error dans __gray_init_handler...

C'est bien si tu arrives à diminuer la taille de TIGCCLIB
Par contre, si tu souhaites vraiment changer l'API de TIGCCLIB pour permettre à l'utilisateur de spécifier quels buffers il veut utiliser, ma lib ne servira plus à grand chose, il faudra qu'on mette nos efforts en communs.

Ce que je fais actuellement n'a pas pour but de rendre ta lib inutile. En particulier, je change pas l'API de TIGCCLIB. Pour le moment, c'est juste un fork optimisé taille (-40 octets, finalement), qui garde la compatibilité VTI et l'utilisation de LCD_MEM sur HW1. Il serait déjà uploadé sur tict.ticalc.org si je n'avais pas des problèmes avec le serveur...

Bon, puisque le serveur de TICT me pose des problèmes, on va faire autrement.
http://databob.free.fr/Volume/files/gray.s

Aussi, voici le diff. C'est un diff unifié, mes modifications sont les "+". Evidemment, il faut avoir l'original...

Il est très facile d'utiliser ce fichier pour passer par-dessus la routine de TIGCCLIB:
* dans un TIGCC Project, ajouter ce fichier au TIGCC project. C'est tout !
* en command-line, il faut rajouter une compilation du fichier .s, et ajouter le .o correspondant dans la commande qui linke.

--- graytigcc.s 2004-03-13 15:34:34.000000000 +0100
+++ gray.s 2005-06-07 16:50:57.387070400 +0200
@@ -8,7 +8,7 @@
| compatible with HW1/HW2 on all AMS versions up to 2.05
|
|
-| $Id: gray.s,v 3.10 2002/04/05 11:34:23 tnussb Exp $
+| $Id: gray.s,v $
|******************************************************************************

|------------------------------------------------------------------------------
@@ -31,7 +31,7 @@
GrayOn:
movem.l %d2-%d7/%a2-%a6,-(%a7)
lea (__switch_cnt,%pc),%a0 | reset plane switch counter to 0
- move.l #0,(%a0)
+ clr.l (%a0)|move.l #0,(%a0)
bsr.s __gray_check_hw_version | evaluate HW version and store it
lea (__gray_hw_type,%pc),%a0
move.w %d0,(%a0)
@@ -73,18 +73,18 @@
beq.s __gray_patches_for_hw1 | if not 1, it is HW2 (or an unknown HW)
|--------------------------------------------------------------------------
| check for VTI (trick suggested by Julien Muchembled)
+ | optimized by Lionel Debroux
|--------------------------------------------------------------------------
- trap #12 | enter supervisor mode. returns old (%sr) in %d0.w
- move.w #0x3000,%sr | set a non-existing flag in %sr (but keep s-flag)
- swap %d0 | save %d0.w content in upper part of %d0
- move.w %sr,%d0 | get %sr content and check for non-existing flag
- btst #12,%d0 | this non-existing flag can only be set on the VTI
- beq.s __gray_hw2type_detected | flag not set -> no VTI
+ trap #12 | enter supervisor mode. returns old (%sr) in %d0.w
+ move.w #0x3000,%sr | set a non-existing flag in %sr (but keep s-flag !!)
+ move.w %d0,%d1 | save %d0.w content in %d1
+ move.w %sr,%d0 | get %sr content and check for non-existing flag
+ move.w %d1,%sr | restore old %sr.
+ lsl.w #3,%d0
+ bpl.s __gray_hw2type_detected | flag not set -> no VTI
|--------------------------------------------------------------------------
| HW1 detected
|--------------------------------------------------------------------------
- swap %d0 | restore old %sr content and return 0
- move.w %d0,%sr
moveq #0,%d0
|--------------------------------------------------------------------------
| patches code for HW1 version
@@ -97,14 +97,12 @@
__gray_patches_for_hw1:
lea (__gray_size_to_allocate,%pc),%a0
move.w #0x0f08,(%a0)
- move.w #0,(__gray_size_to_add-__gray_size_to_allocate,%a0)
+ clr.w (__gray_size_to_add-__gray_size_to_allocate,%a0)|move.w #0,(__gray_size_to_add-__gray_size_to_allocate,%a0)
rts
|--------------------------------------------------------------------------
| HW2 detected
|--------------------------------------------------------------------------
__gray_hw2type_detected:
- swap %d0 | restore old %sr content and set return to 1
- move.w %d0,%sr
.ifdef ALWAYS_HW2_TESTING
__always_hw2_proceed:
.endif
@@ -153,12 +151,12 @@
cmp.b #8,%d0
beq.s __gray_proceed_old | for value 8 we do nothing (dark plane
| stays active)
- lea (__D_plane,%pc),%a0
+ lea (__D_plane,%pc),%a0
|--------------------------------------------------------------------------
| doublebuffer extension ... add content of __gray_dbl_offset to %d0
|--------------------------------------------------------------------------
- add.w (__gray_dbl_offset-__D_plane,%a0),%d0
- suba.w %d0,%a0
+ add.w (__gray_dbl_offset-__D_plane,%a0),%d0
+ suba.w %d0,%a0
move.l (%a0),%d0 | load the address of this plane
lsr.l #3,%d0 | reduce to address / 8
move.w %d0,0x600010 | set new plane startaddress
@@ -202,11 +200,10 @@
| HeapAllocHigh(HW1=3848 bytes or HW2=7688 bytes)
|--------------------------------------------------------------------------
movea.l 0xc8,%a0
- lea (0x92*4,%a0),%a0 /* HeapAllocHigh */
+ movea.l (0x92*4,%a0),%a2 /* HeapAllocHigh */
.word 0x4878 | opcode of "PEA #value"
__gray_size_to_allocate: | the size gets patched !!
.word 0x1e08
- movea.l (%a0),%a2
jsr (%a2)
addq.w #4,%a7
move.w %d0,(%a5)+ | store handle in handle variable
@@ -217,8 +214,7 @@
|--------------------------------------------------------------------------
move.w %d0,-(%a7)
movea.l 0xc8,%a0
- lea (0x96*4,%a0),%a0 /* HeapDeref */
- movea.l (%a0),%a2
+ movea.l (0x96*4,%a0),%a2 /* HeapDeref */
jsr (%a2)
addq.l #2,%a7
|--------------------------------------------------------------------------
@@ -384,7 +380,7 @@
neg.w %d1
movea.l (__gray_used_mem,%pc,%d1.w),%a0

- lea 0x4C00,%a1
+ lea 0x4C00.w,%a1
adda.w %d0,%a0
adda.w %d0,%a1
movem.l (%a0)+,%d0-%d7/%a2-%a6
@@ -474,7 +470,6 @@
lea (__L_plane,%pc),%a0
move.w #0x3BF,%d1
move.w (__gray_hw_type,%pc),%d0
- tst.w %d0
beq.s __gray_init_hw1_handler

|--------------------------------------------------------------------------
@@ -488,7 +483,7 @@
|--------------------------------------------------------------------------
movea.l (__gray_used_mem,%pc),%a1
move.l %a1,(0x4,%a0) | set __D_plane
- movea.w #0x4C00,%a0
+ lea 0x4C00.w,%a0
move.w %d1,%d0
__gray_cpy_d_plane:
move.l (%a0)+,(%a1)+
@@ -515,9 +510,11 @@
lea (__gray_int1_handler_hw1,%pc),%a0
move.l 0x64,(__gray_old_int1_hw1 - __gray_int1_handler_hw1,%a0)
__gray_init_proceed:
- bclr.b #2,0x600001
- move.l %a0,0x64:w
- bset.b #2,0x600001
+ move.l %a0,%d2
+ lea 0x600001,%a0
+ bclr.b #2,(%a0)
+ move.l %d2,0x64:w
+ bset.b #2,(%a0)
__gray_clr_l_plane:
|--------------------------------------------------------------------------
| clear light plane (done for both HW types)
@@ -530,8 +527,7 @@
move.l #0xEF007F,-(%a7)
move.l (__D_plane,%pc),-(%a7)
movea.l 0xC8,%a0
- lea (0x1A2*4,%a0),%a0 /* PortSet */
- movea.l (%a0),%a1
+ movea.l (0x1A2*4,%a0),%a1 /* PortSet */
jsr (%a1)
addq.w #8,%a7
__gray_ok:
@@ -550,17 +546,17 @@
lea (__gray_handle,%pc),%a3
tst.w (%a3)
beq __gray_off_out | no handle? -> nothing to do
+ lea 0x600001,%a0
move.w (__gray_hw_type,%pc),%d0
- tst.w %d0
beq.s __gray_hw1_cleanup
|--------------------------------------------------------------------------
| cleanup for HW2 calcs
|--------------------------------------------------------------------------
- bclr.b #2,0x600001
+ bclr.b #2,(%a0)
move.l (__gray_old_int1_hw2,%pc),0x64:w | restore old INT1 handler
- bset.b #2,0x600001
+ bset.b #2,(%a0)
movea.l (__D_plane,%pc),%a1
- movea.w #0x4C00,%a0
+ lea 0x4C00.w,%a0
move.w #0x3BF,%d0 | copy content of darkplane to 0x4c00
__gray_dark2lcd:
move.l (%a1)+,(%a0)+
@@ -571,30 +567,32 @@
| set it)
|--------------------------------------------------------------------------
__gray_hw1_cleanup:
- move.w #0x980,0x600010 | restore used plane to 0x4c00
+ move.w #0x980,(0x600010-0x600001,%a0) | restore used plane to 0x4c00
move.l (__gray_old_int1_hw1,%pc),0x40064 | restore old INT1 handler
| (We can use 0x40064 here because it is HW1 only.)

__gray_continue_cleanup:
lea (__L_plane,%pc),%a0 | restore plane pointers to 0x4c00 for sure
- move.l #0x04c00,(%a0)+
- move.l #0x04c00,(%a0)+
- move.l #0x04c00,(%a0)
+ lea 0x4C00.w,%a1
+ move.l %a1,(%a0)+
+ move.l %a1,(%a0)+
+ move.l %a1,(%a0)
+ |move.l #0x04c00,(%a0)+
+ |move.l #0x04c00,(%a0)+
+ |move.l #0x04c00,(%a0)
|--------------------------------------------------------------------------
| HeapFree(__gray_handle)
|--------------------------------------------------------------------------
movea.l 0xc8,%a0
- lea (0x97*4,%a0),%a0 /* HeapFree */
+ movea.l (0x97*4,%a0),%a2 /* HeapFree */
move.w (%a3),-(%a7)
- move.l (%a0),%a2
jsr (%a2)
addq.l #2,%a7
|--------------------------------------------------------------------------
| PortRestore()
|--------------------------------------------------------------------------
movea.l 0xc8,%a0
- lea (0x1A3*4,%a0),%a0 /* PortRestore */
- move.l (%a0),%a2
+ movea.l (0x1A3*4,%a0),%a2 /* PortRestore */
jsr (%a2)
clr.l (%a3) | 0->handle AND(!!) 0->__gray_dbl_offset
lea (__gray_sync_n_count,%pc),%a0
@@ -608,6 +606,11 @@
| #############################################################################
|
| $Log: gray.s,v $
+| Revision 3.12 2005/06/07 16:51:00 Lionel Debroux
+| Optimized the routine for size: saved 40 bytes.
+| I plan on making a version which always uses two consecutive planes outside
+| of LCD_MEM, even on HW1.
+|
| Revision 3.11 2004/02/25 03:49:03 Kevin Kofler
| Don't use 0x40000 to set interrupts on code path that affect HW3.
| Use 0xE00000 as ROM_base mask instead of 0x600000.

- lea 0x4C00,%a1 + lea 0x4C00.w,%a1

AS optimise pas ca ?

Si, il semble qu'il le fait (mettre des 0x64.w à la place de 0x64 ne change rien).

As-tu vu l'edit ?