Martial Demolins (./1) :
La question que je me pose est de savoir si il convient mieux d'établirue convention de destruction des registres (genre d0-d2/a0-a1, au hasard) pour chaque fonction, ou s'il est plus avantageux de faire sauvegarder et restaurer les registres par chaque fonction? Je suppose que ceux qui ont de l'expérience dans les programmes de taille asuront me répondre.

Ce qui est important est de faire une convention et de d'y TENIR.
Autre chose, toujours noté en entéte de fonction, les entrées, les sorties et ce qu'elle détruit.

Martial Demolins (./1) :
est-il une bonne idée, du fait de coder en assembleur, d'utiliser au mieux les instructions du proc pour accéder aux variables (s'y déplacer avec de la pré-décrémentation ou post-incrémentation, ce qui peut entrainer nu vrai bazar si on change de place une variable), ou êtes-vous plutôt partisan d'un code qui va accéder nominativement aux variables qui sont utilisées?

Ca dépend de la criticité en taille ou en vitesse de ton code.
Si ton code fait 40K, et que c'est appelé une fois par seconde, ca ne vaut pas la peine.

Martial Demolins (./1) :
Sur un source de bonne taille et d'une relative complexité, la seconde solution est peut-être la meilleure?

Tout dépend.

Martial Demolins (./3) :
Pour les registres, j'ai vu que PreOS sauvait puis restaurait souvent tout ce qu'il utilise, alors je me pose la question.

Preos est un cas particulier: il essaye d'être le moins chiant possible envers le programme qui l'utilise.
On ne peut pas du tout généraliser.

Thibaut (./4) :
Un bon code en C peut donner quelque chose de presque aussi efficace qu'on bon code en assembleur.

Tout dépend si on fait de la logique décisionnel ou du calcul.
Dans le second cas, l'asm continue d'être une très bonne arme, même sur les procs actuels avec les compilateurs les plus efficaces.

Martial Demolins (./5) :
*hem*, pour avoir décompilé du C compilé avec TIGCC/GCC4, je peux te dire qu'on y voit des délires : aucun registre utilisé, lecture sur la pile ou accès à une variable à chaque itération d'une boucle etc... Niveau vitesse, on est loin de l'asm.

Le backend 68k de GCC n'est plus vraiment maintenu depuis des années. On a un sous gcc pour 68k.