Toujours un petit problème de ROM CALL (toujours elles)! - Page 3

Par nature c'est biaise. On peut comparer un semble de programmes entre eux, pas un programme dans l'absolu.
Les comparer en considerant qu'il est seul poossède aussi un biais, puisque c'est neglige l'environnement dans lequel il nage.

P'tite question qui pourrait paraitre conne et hors de propos, mais bon j'suis qu'un débutant aprés tout

Qui signifie
.word ... ou .byte ... ou .long ...

Car je suis en train de faire un fichier include pour CC pour le niveau de gris.
La, je tombe sur un truc du genre:

__gray_old_int1_hw1:
.long 0x00000000
__gray_dummy1:
.byte 0x00
__gray_phase1:
.byte 0x01
__gray_phase2:
.word 0x06

Faut que je le remplace par koi pour que AS le reconnaisse

.long -> dc.l
.byte -> dc.b
.word -> dc.w

Laisse tomber le portage pour AS, c'est très compliqué ...
Il vaut mieux que quelqu'un connaissant très bien l'assembleur et utilisant AS et CC s'en occupe ...
(ExtendeD ? )

J'adore ton pseudo

Tu es un cousin à Jean Kulthamer ?

Oui

Au fait pour vos questions d'approximations, je verrai bien un DL₃(0)

Je fait des progrés tout de même! et l'asm, y'a rien de sorcier la dedans.
En ce qui concerne gray.h (avec TIGCC) je suis effectivement en train de faire un portage sur CC (donc AS) dans un fichier appelé "gray_h" (pour le nom, je me suis déchiré

Bien sur, je m'inspire (quelque peu) sur les sources du fichier gray.s (avec les sources de TIGCC).

Pour cela, quelques petites questions:
1. J'ai viré tous les symboles '%'. Bonne idée?
2. un truc du genre 0x10000 remplacer par $10000, OK?
3. quand j'ai LEA (label,pc),a0, je met à la place LEA label(pc),a0
4. Es-ce que AS reconnait:
move.l d0, label1-label2(a0)
5. Enfin, quand j'ai move.l d0,(label1-label2,a0) je le remplace par ce qu'il y a en 4.

Donc ce serait cool si o pourrait me dire si je part dans la bonne direction ou non

Oui pour tout

guigui17
a écrit : 1. J'ai viré tous les symboles '%'. Bonne idée?

Oui.

2. un truc du genre 0x10000 remplacer par $10000, OK?

Oui.

3. quand j'ai LEA (label,pc),a0, je met à la place LEA label(pc),a0

Correct.

4. Es-ce que AS reconnait: move.l d0, label1-label2(a0)

Il faut demander à Nitro là. Il est censé le reconnaître en tout cas.

5. Enfin, quand j'ai move.l d0,(label1-label2,a0) je le remplace par ce qu'il y a en 4.

Correct.

Donc ce serait cool si o pourrait me dire si je part dans la bonne direction ou non

Oui.

guigui17 a écrit :
4. Es-ce que AS reconnait:
move.l d0, label1-label2(a0)

Oui il le reconnait, mais malheureusement il rajoute une entrée dans la table de relogements (il faudrait que je fasse une detection de soustraction de deux labels relogeables pour enlever ce relogement... enfin bref c'est la merde), ce qui fait que finalement ça va planter
Donc il faudra calculer ça à la main j'en ai bien peur...

Ou alors attendre le successeur de AS, mais c'est pas pour demain.

J'ai repris les routines de gray de graphlib pour faire une gray.h oncalc et ça marche.

Nitro : Je crois qu'il y a toujours un problème pour AS au niveau des labels locaux qui se suivent.

Pour faire ma routine gray_h pour AS (et donc CC), je me suis inspiré des toutes dernière sources livrées avec TIGCC (version 0.94 beta 18), ca a l'air de marcher mieux que la version 0.93. Mais bon, ca marche pas trop tout de même

Eh ExtendeD, c vrai qu'elle marche bien te routine GRAY reprise de Graphlib avec AS et CC
Faut que je matte les sources

Donc, si j'ai bien compris,

move.l d0, label1-label2(a0)

copie le contenu de d0 dans l'adresse pointée par a0+(contenu Label1-contenu Label2)?
Exacte??

De plus, comment pourrait t'on remplacer cette intruction avec des SUB ou des ADD par ce qu d'apres ce que j'ai compis, avec AS, c pas trop la peine d'y compter

Le problème est l'expression label1-label2 elle-même.
Ce qu'il faut faire, c'est compter la taille qu'il y a entre les 2 labels, et mettre cette taille à la place de l'expression.
Les SUB et ADD ne t'avanceront en rien.

A, moi je pensais que s'était selon le contenu...
Donc, la valeur est fixe une bonne fois pour toute!

Le problème va être de compter maintenant

Bon, déjà __gray_size_to_add-__gray_size_to_allocate vaut 48. Ou peut-être 50 si AS code le movea.l 0xc8,%a0 en movea.l 0xc8:l,%a0 plutôt que movea.l 0xc8:w,%a0.

__L_plane - __gray_used_mem = -8
Reste à calculer __gray_old_int1_hw2 - __gray_int1_handler_hw2 et __gray_old_int1_hw1 - __gray_int1_handler_hw1.

Faudrai une doc sur la taille en octet de chaques intruction

Rajoute les intstructions pour le calculer a la volee.

guigui17 a écrit :
Faudrai une doc sur la taille en octet de chaques intruction

topics/14527-compteur-de-cycles/2#31

Voilà le gray.h et le gray.a on-calc créés à partir du GraphLib de PreOS : [URL]http://membres.lycos.fr/extended/cc_gray.zip[/URL]

C bon, je suis sur le point de finir ma routine de gestion des gris pour CC et AS. Désolé ExtendeD, je continu sur ma lancée (ca me fait vraiment chier d'abandonner maintenant alors que j'avais presque fini) mais j'ai tout de même regarder la tienne. Pour info, elle utilise la routine "gray.s" livrée dans les sources de TIGCC version 0.94 beta 18.

-

> ExtendeD :
Je t'adore

Elle a l'air moin chaude a programmer que celle de TIGCC celle de Graphlib. Enfin bon, aprés, je ne sait pas la quelle est la plus optimisée

J'était sur le point de finir quand... plus de batterie Encore a attendre 10h pour qu'elles se rechargent c de piles.

guigui17 a écrit :
Elle a l'air moin chaude a programmer que celle de TIGCC celle de Graphlib. Enfin bon, aprés, je ne sait pas la quelle est la plus optimisée

Je ne sais pas. La notre (TIGCC) a plus de fonctions en tout cas.
Ce que je sais est que Thomas a, dans les dernières versions, optimisé notre routine en taille par rapport à la version de JM. Mais je n'ai pas comparé la taille avec celle des routines de PpHd.

Enfin, s'était chaud a transcrire pour que AS comprenne.... Mais j'ai reussi!

Connaissant JM et son code, je doute qu'il est fait baisser la conso memoire de la routine de JM. Plutot son implantantion

Bah TN n'a pas du faire faire beaucoup plus que réduire le nombre de movem dans la routine de copie