ASM -> C - Page 2

Galmiza> grüt ? code appellant = C ou asm ? code appellé = C ou asm ?

Je pense qu'il a fait une fonction ASM et qu'il l'appelle à partir d'un code C.

Bah alors je vois pas comment il peut savoir qu'il y a 0xAAAA7777 dans la fonction appellante ? Si c'est ce que tu dis, alors il n'y a pas du tout à s'en préoccuper, il suffit de ne détruire que d0-d2/a0-a1...

Donc, il faut (pour optimiser) que je modifie toutes mes fonctions assembleur:
ex: movem.l d0-d7/a0-a6, -(a7) -> movem.l d3-d7/a2-a6, -(a7)
Et ce quels que soient les parametres, c'est bien cela ?

Oui.
Cependant, ton contexte n'est pas clair. Tu peux répondre à ./31 ?

Ouais Pollux, c'est vrai, mais c'etait un exemple pour savoir si tout le registre etait modifié (poids fort et faible).

Reponse au 30:

J'appelle des fonctions assembleur depuis un code en C.

Tout compte fait, je vais rester dans le 100% assembleur car avec le C-ASM, j'ai tout autant de bug, sinon plus qu'avant.
De plus, ces bugs sont completement incomprehessibles (pour moi ), genre quand dans mes fonctions ASM je sauve tous les registres afin de les restaurer à la fin ca bugge, alors que quand je ne les sauve pas, ca ne bugge pas .

100% C, c'est super, 100% assembleur aussi mais dès que je mélange les 2 ..... c'est la merde !

Bon j'ecris pas que pour rien non plus . Dans tigcc, si je fais du 100% assembleur, j'aurais pas de mauvaises surprises, par exemple "hé oui ca bugge parce tigcc remplace ça par ci et ci par ça" ?

Sauf si tu fais du code très subtil non (en fait ça doit poser problème surtout pour le code auto modifiant), tu n'auras pas ce genre de problème
Pour ton histoire de restauration, euh... t'es sûr de toi?

regarde si le switch -d est bien activé, ça peut foutre la merde sans prévenir. Ca m'a buggué plusieurs programmes, en supprimant certaines instructions

100% sûr du probleme de restauration ! Et le code en question n'est pas subtil du tout.

Flanker, as-tu eu ces problèmes en faisant du C+ASM ou que de l'ASM ?
Parceque l'histoire du switch... (je ne sais meme pas ce que c'est un switch).

L'interface de tigcc est tres confortable, bien plus que celle de NotePad .
Mais ce que j'espere, c'est de ne pas rencontrer de problemes dûs a tigcc.

A propos de bugs chelou: (version 2.71-F2)
la compilation se deroule mal quand dans un fichier externe (je veux dire un .asm) on a un nombre impair d'octets. Le compilateur renvoie un message ultra tordu (un "alignement error" sur n'importe quelle fonction du code).

rajoute un even à la fin
sinon pour le coup de la restauration je peux voir le code et connaitre l'erreur retournée ?

Flanker, as-tu eu ces problèmes en faisant du C+ASM ou que de l'ASM ?
Parceque l'histoire du switch... (je ne sais meme pas ce que c'est un switch).

les switchs, c'est les options passées en ligne de commande à l'assembleur, ils se règlent dans options du projet -> a68k, et tu rajoutes -d
c'était 100% ASM pour a68k


ta fonction renvoyait un résultat ou pas ?

Le code est tres tres gros !
Je poste la fonction asm qui foire + le C qu'il y a autour mais je ne sais pas si ca sera suffisant...

La fonction a pour but d'afficher un sprite sur une grande mémoire de 64B de large (c'est pour comparer differentes méthodes de scrolling). L'image n'est affiché qu'a des coordonnées multiples de 16 donc pas besoin de faire rouler des bits. Les coordonnées parametres sont deja /16.
Elle est pas encore optimisée car "make it work and thenmake it fast".

;extern void FastDraw16(register signed short asm("d0"), register signed short asm("d1"),
; register signed short asm("d2"),
; void* sprite asm("a1"), void* silhouette asm("a2"), void* destination asm("a0"));
FastDraw16:
movem.l a2-a6/d3-d7,-(a7)

; movem.l a2-a3,-(a7)
; movem.w d3,-(a7)

subq.w #1,d2 ;pour la boucle de hauteur

lsl.l #6,d1 ;multiplication par 64 (largeur de l'ecran)
lsl.l #4,d1 ;multiplication par 16 (hauteur des cases)
lsl.l #1,d0 ;sprite de 2 octets de large
add.l d0,d1
add.l d1,a0 ;l'octet a modifié est pointé

move.w a2,d1
beq.s \affs
move.w d2,d3
move.l a0,a3
\transp
move.w (a3),d1
moveq.w #0,d0
move.w (a2)+,d0 ;a2 pointe la silhouette
not.w d0
and.w d0,d1
move.w d1,(a3)
lea.s 64(a3),a3
dbra.s d3,\transp

\affs
move.w (a0),d1
move.w (a1)+,d0 ;a1 pointe le sprite
or.w d0,d1
move.w d1,(a0)
lea.s 64(a0),a0
dbra.s d2,\affs

\pass_no_sprite
; movem.w (a7)+,d3
; movem.l (a7)+,a2-a3

movem.l (a7)+,a2-a6/d3-d7
rts

Et un peu du code qui l'appelle:

// Affiche un sprite en tenant compte de la transparence et des dimensions
void dispBGSprite(unsigned short* sprite, unsigned short i, unsigned short j)
{
void* transp;
unsigned short a,b,c;

a=*(sprite++); // Transparence
b=*(sprite++); // Largeur
c=*(sprite++); // Hauteur
transp = sprite + 2*16; // Adresse Silhouette

if (b==2)
{
if (a=1)
{
FastDraw16(i,j,c, sprite, transp, map_clair);
FastDraw16(i,j,c, sprite+16, transp, map_fonce);

}
else
{
FastDraw16(i,j,c, sprite, NULL, map_clair);
FastDraw16(i,j,c, sprite+16, NULL, map_fonce);
}
}

else if (b==4)
{
if (a=1)
{
FastDraw32(i,j,c, sprite+16, transp, map_fonce);
FastDraw32(i,j,c, sprite, transp, map_clair);
}
else
{
FastDraw32(i,j,c, sprite+16, NULL, map_fonce);
FastDraw32(i,j,c, sprite, NULL, map_clair);
}
}
}

Donc ca marche mais il y a le probleme avec les registres.

Edit: la fonction ne renvoie rien.

tu trouves que c'est beaucoup comme code asm ?

le bug, c'est quand tu remplaces
movem.l (a7)+,a2-a6/d3-d7

par

 ; movem.w (a7)+,d3
; movem.l (a7)+,a2-a3

?

Nan mais en tout ya trop de code pour tout poster !

et ça fait quoi comme erreur ?
tu utilises quoi comme switches de compilation ?

Oups, en relisant le code que j'ai posté, j'ai vu une faute dans le C (a=1 => a==1)

J'étais persuadé que ca venait de l'ASM.

Le bug est different maintenant....

lol

J'utilise les switches par defaut.

L'erreur "etait" au niveau graphique. Les sprites apparaissaient bizarrement mais ce n'etait pas une simple erreur d'adressage.

Si ça avait été un problème de restauration des registres, tu peux être sûr à 99% que tout aurait planté

Je suis trop con !!!!!
Je me suis fait chié ULTRA longtemps à modifier le code ASM pour réparer, et comme yavait des changements, j'étais absolument persuadé que ca venait de là !!!

Maintenant ca marche, juste en ajoutant un vieux caractere "=".

Merci !!! sans vous j'aurais pas posté le code et je serais toujours en train de chercher dans le vide !

Et merci pour les renseignements !

erf j'avais regardé que ton code asm

mais oui if (a=1) c'est classique et vicieux

Clair !
Et dire que j'allais arreter le C sur ti89 à cause de cette vieille erreur !
Mais c'est vrai qu'en assembleur ca n'existe pas de telles erreurs....

d'ailleurs, fais gaffe à ton movem.w (a7)+,d3, il me semble que d3 est écrit sur 32 bits et pas 16

Galmiza > normalement si tu mets tous les warnings (-W -Wall, je ne sais plus lequel des deux met le warning qui va bien), ça te prévient dans ces cas-là ^^

Flanker> Oui, je confirme.

Vous êtes sûrs ?
d3 est utilisé pour la boucle.
A la fin de la boucle, il vaut -1 sur les 32 bits ?

Non, sur 16 bits seulement, mais un movem.w réalise une extension du signe avant d'écrire dans les registres, donc il affecte les 32 bits