Debut en asm (encore 1 :)) - Page 1

Bon je commence en asm, tout allait bien, jusqu'au moment ou j'ai voulu mettre les fonctions dans des fichiers different parceque ca commencait a etre le bordel (en essayant de m'inspirer de la source de phx).

Alors, j'ai 3 fichier, le premier, y'a

xdef nostub...
xdef ti89
xdef ti92plus

include Init.asm
main_prgm:
quelques instructions (avec utilisation de sous prgm de GFX.ASM)
rts

include GFX.asm

Le second y'a

include OS.H

sauvegarde des registre,
tst memoire suffisante?
beq nomem
sauvegarde de l'ecran, tout le tsoin tsoin pompé sur le tuto de KK

bsr main_prgm
je remet l'ecran
nomem:
je rebalance les registres

rts ;et la j'aimerais que ca revienne au depart

bon et le troisieme y'a du code de quoi afficher un sprite 8*8
d'ailleur si vous pouvez me dire ce que vous en pensez

Afficher_piece:
move.l #7,d0 ;initialise le compteur
lea $4c00,a1 ;adresse de l'ecran
move.l d5,d1
lsl.l #3,d1
lea Pieces(pc,d5.l),a0 ;On charge la ligne
add.l d6,a1
move.l d7,d1
mulu #240,d1
add.l d1,a1
afloop:
move.b (a0)+,(a1) ;on balance le bit sur l'ecran et on passe au bit suivant
add.l #30,a1 ;ligne suivante
tst d0 ;Test de fin de boucle
dbcs d0,afloop ;sinon, on revient en haut
rts ;et on repart

Bon le bleme c'est surtout que j'ai un beau Duplicate Symbol a la fin de main_prgm


Je pense que le probleme viens du fait que le prog ne commence pas au bon endroit...enfin je sais pas trop... enfin, je pense qu j'ai fait un peut n'importe quoi et que c'est pour ca que ca foire...

Merci aux gens qui veulent bien me donner un coup de main

tu compiles comment ?

moveq permet de charger un entier sur 8 bits (un octet).

addl.l #30,a1 -> lea.l 30(a1),a1

pour le move, j'ai lu je sais plus ou que ct directement optimisé par l'assembleur.
Si je met LCD_MEM, faut il que je fasse une detectionde Hardware?
Bon tout de maniere, je vais ecrire dans un ecran virtuel donc c'est pas tres grav.
Sinnon pour le bit, mes comment sont fait a la nimp... c pas tres important.

Pour adda, je vais voir ca...

Pollux: j'en sais rien j'utilise TIGCC, avec les options de base g rien touché.

D'ailleur, je sais pas comment on fait pour definir le dossier des fichier include (pour l'instant je les ai mis dans le dossier ou il y a os.h

c quoi, c'est une Macro? LCD_MEM contient une fonction de HW
Ok je vais virer les options de TIGCC, mais pourquoi il les met si c merdique?

Bon sinon, les optimisations je m'en branle un peu ct surtout l'organisation de mon programme qui me souci le plus pour l'instant. Alors si quelqu'un a une solution

bon, ca marche, je te mail ca ce soir,

Bon, sinon, interressant le debuguer faut que je regarde ca de plus pres

Vu la syntaxe, tu utilises A68k, non ? A68k accepte des instructions complètement invalides (moveq.w, etc.).

Ouais, sinon, personne peut epondre a mon post 1.???
Et martial, ca chie un peu l'internet chez moi donc je sais pas si je vais pouvoir t'envoyer le source.

tu peux pas l'uploader ? là on n'a pas assez d'infos
sinon, essaie de comment chaque include de fichier

Non, internet chie chez moi, sinon, le premier est le prog principal (tetris.asm )
le second est init.asm
le troisieme est gfx.asm

En fait je croit que ca foirait parcequ'il manquait un espace devant un rts.

Sinon, j'ai un autre souci. C'est pour
lea piece(pc),a0
btst.w #3,(a0)
beq pouet
.
.
.
piece %1111100110011001

il me test bienle bit en gras? ou pas

ouep
mais faudrait plutôt mettre

piece:
 dc.w  %1111100110011001 

en fait la merde c'est que ca marche pas, ca test le bit (8+3)

Bon, j'ai fait une routine pour afficher un carre de 4*4 sprite

Afficher_Piece: ;Argument sur la pile:initialise le compteur
move.w 8(a7),d0
lsl.w #1,d0
lea Pieces(pc,d0.w),a2 ;On charge la ligne. J'ai une erreur du compilateur ici, si je vire pas les instruction foireuses (cf ci dessuos)

move.w 8(a7),-(a7); argument pour afficher_sprite
move.w 8(a7),-(a7)
move.w 8(a7),-(a7)

move.l #3,d3 ;on commence a y+3
AP0_loop:
move.l #3,d2 ;a x+3
;cmp.w #1,d3 ;les 3 instruction qui font foirer
;bne afc

;afc:
AP1_loop:
move.w d3,d0
lsl.w #2,d0
add.w d2,d0
sub.w #15,d0
sub.w d1,d0
neg.w d0 ;bon a ce moment, d0 doit contenir le bon bit (entre 0 et 15)
btst.w d0,(a2) ;Le bleme est ici, puisque ca test toujours les bits de 8a 15
beq APcontinue
add.w d2,2(a7) ;on met a jour x
add.w d3,(a7) ;on met a jour y
bsr Aff_Sprite ;affiche le sprite
sub.w d2,2(a7) ;on met a jour x
sub.w d3,(a7) ;on met a jour y

APcontinue:
dbra d2,AP1_loop ;sinon, on revient en haut
dbra d3,AP0_loop ;sinon, on revient en haut
addq.l #6,a7
rts

Pieces:
dc.w %1111000100100001
dc.w %1111011000111100

Bon est ce que vous avez une routine qui marche pour tester les bits dans un word??, parcequ'avec des add ca marche pas non plus (cf ca me fait une merde comme dans la ligne lea...)

btst.w n'existe pas

c'est btst.b pour les acces mémoire, et btst.l qd tu testes un registre ^^

[cite] Ok je vais virer les options de TIGCC, mais pourquoi il les met si c merdique? |/cite]C'est pas merdique, ça améliore énormément la rapidité et la taille du code généré par rapport à si tu les désactives. Par contre, le code optimisé est beaucoup plus dur à comprendre que le code brut, c'est pour ça qu'on te dit de virer les optimisations pour débugger.
Bien sûr quand ça marchera tu recompileras, mais avec les optimisations cette fois

je crois qu'il parle des optimisations du linker, spectras, pas du compilo...

Pas sûr. Les optimisations de l'assembleur (ici A68k, je suppose), sont plus difficiles à comprendre (lea x(an),an -> addq/subq si abs(x)<8) que les optimisations du linker (qui sont très souvent des xxx.l -> d(pc)).

c'est pas activé par défaut ca, en principe... (peut-etre dans l'IDE ?)
et les optimisations du linker peuvent (pouvaient ?) casser du code valide

il doit falloir rajouter -n aux switchs a68k pour désactiver les optimisations si je me souviens bien

oui, mais il y a plusieurs niveaux d'optimisations si mes souvenirs sont bons (mais bon, j'ai pas touché a ca depuis gtools ) :
- aucune optimisation
- optimisations par défaut : move.l => moveq, add.w => addq.w, etc...
- optimisations supplémentaires : add.l #30,an => lea 30(an),an, lea 8(an),an => addq #8,an (activables par un switch)

Disons que les optimisations en assembleur c'est seulement utile qd on veut faire des macros ou utiliser des constantes qu'on est susceptible de faire varier, pas pour écrire du code "normal"...

#22: exemple de code valide (et bien écrit, pas d'offsets codés en dur par exemple...) qui est cassé ?

y a eu plusieurs topics dessus qd kevin était pas encore banni...

Je vais voir ça.
Ceci dit, les optimisations du linker, tant qu'elles sont correctes, sont extrêmement utiles. Voir la place gagnée sur un gros programme...

[EDIT: je vois que Kevin s'est plaint du fait que les bug reports soient éparpillés, ça ne m'étonne pas que ce soit si difficile à rechercher...]

Lionel Debroux :
Je vais voir ça. Ceci dit, les optimisations du linker, tant qu'elles sont correctes, sont extrêmement utiles. Voir la place gagnée sur un gros programme...

Ben oui, qd y a plusieurs fichiers objets c'est utile... Mais bon c'est implémenté comme un gros hack, si ca avait été géré au niveau de l'assembleur ca aurait été bcp plus simple et fiable tout en restant aussi efficace... La tel que c'est implémenté ca inspire vraiment pas confiance

[EDIT: je vois que Kevin s'est plaint du fait que les bug reports soient éparpillés, ça ne m'étonne pas que ce soit si difficile à rechercher...]

t'as qu'a les mettre sur tiwiki

C'est pas idiot ça En plus ça se ferait super vite, il suffirait de faire une catégorie ou un namespace dédié aux bug reports, y'en a pour 15 minutes à tout casser pour mettre ça en place. Si des gens sont intéressés, c'est faisable.