ASM -> C - Page 3

Galmiza
: Le code en assembleur est precédé de: section ".data" lors de la création du fichier source ASM.

Ce n'est plus nécessaire avec TIGCC 0.95, et même déconseillé (parce que ça désactive les optimisations du linker pour ce fichier).

Flanker
: 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

C'est activé automatiquement maintenant (depuis pas mal de bêtas déjà).

Galmiza :
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).

Tu n'aurais pas ça si ton fichier était vraiment externe (c'est-à-dit compilé séparément, pas inclus à la barbare avec include).

J'ai un énorme doute sur le fait que Tigcc sauvegarde d0-d2/a0-a1:

Voici 2 screenshots:
L'un d'un morceau de code avec une fonction assembleur qui sauve d0-d2/a0-a1, et l'autre du meme morceau mais dont la fonction assembleur ne sauvegarde pas d0-d2/a0-a1. (en fait ici, c'est le d1 fait "bugger")

Voici un peu du code C qui l'appelle:

Scrolling(xMap,yMap,map_fonce,v_screen);
Clipper16(xCur,yCur,16,(arbuste+16+3),(arbuste+2*16+3),v_screen);
copyToPlane(v_screen, GrayGetPlane(DARK_PLANE));

Scrolling(xMap,yMap,map_clair,v_screen);
Clipper16(xCur,yCur,16,arbuste+3,(arbuste+2*16+3),v_screen);
copyToPlane(v_screen, GrayGetPlane(LIGHT_PLANE));

Lorsque je remplis le plan clair apres le foncé, c'est le clair qui "deraille". (cf screens)
Mais quand le remplis le plan clair avant, c'est le plan foncé qui pose probleme.

Edit: les 3 fonctions sont en assembleur (pour les tests, seule Clipper16 ne sauve pas tous les registres)

Bah regarde le code généré pour t'en convaincre, mais c'est le cas normalement.

d0-d2/a0-a1 sont détruits par toute fonction C, nan ?

Comment ça ?

Si tu fais
void f(void)
{

}

Et que tu appelles cette fonction, quelque part, il y a pau de chance que d0-d2/a0-a1 aient été détruit.

je voulais dire qu'ils sont considérés par le compilateur comme étant détruits par toutes fonctions C, et c'est très souvent le cas

Ah oui, le comilo considère que tu as le droit de détruire d0-d2/a0-a1 dans une fonction, donc quand il fait appel à une fonction, il sauvegarde ces registres puisqu'ils risquent d'être détruits.

Plus précisément, il essaye de ne pas les utiliser...

Quelques infos ici : http://tigcc.ticalc.org/doc/asminfo.html