Stratégie registeresque et autres habitudes - Page 1

AMHA, une fonction est censée suivre la convention d'appel, donc %d0-%d2/%a0-%a1 détruits.

Quant à l'accès aux variables, utiliser la postincrémentation et la prédécrementation est la bonne solution. Mais pourquoi pas écrire en C, comme ça tu accèdes aux champs par nom et GCC en fait quelque chose d'efficace. (Enfin bon, il faut dire que la conversion automatique en postincrémentation ou prédécrementation n'est pas vraiment au point.)

Martial Demolins (./3) :
Je ne code pas en C parce que sur de l'embarqué, c'est de la perte de vitesse et surtout de place.

Un bon code en C peut donner quelque chose de presque aussi efficace qu'on bon code en assembleur. Les compilateurs optimisent plutôt bien. Programmer en assembleur apporte peu de taille en moins je pense. Quand à la vitesse, la différence doit être minime aussi en général (mais elle n'est pas négligeable dans certains cas critiques).

Ca dépend pour quoi et surtout de la manière dont tu codes, comme dit Pollux à raison
Un programme en C codé consciencieusement donne un code ASM très respectable. J'ai retiré "surtout GCC" de mon message parequ'en effet, au niveau de la vitesse, il n'est pas toujours le meilleur.
Si tu as le temps, regarde du côté du code généré par GTC. Il donne des binaires plus de 10% plus rapides que GCC quand le code C est bien fait.
Je ne pense pas qu'on soit très loin de l'efficacité d'un code ASM dans la plupart des utilisations.

Ouai... PpHd a ses opinions quoi

J'ai jamais dis ça Et depuis le début je précise que mon avis ne concerne pas tous les cas.
Allez hop, on arrête le HS ?

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.

Le Maître a parlé.

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

Pas vrai, il y a eu un peu de refonte pour GCC 4.3. D'ailleurs, il faudra que je porte notre patchset pour GCC 4.3 (je vais sauter la 4.2).

Kevin Kofler (./13) :
Pas vrai, il y a eu un peu de refonte pour GCC 4.3. D'ailleurs, il faudra que je porte notre patchset pour GCC 4.3 (je vais sauter la 4.2).

Il faudrait beaucoup.

Es-tu volontaire?

Moi ma philosophie de la chose c'est qu'on s'en fout du langage dans lequel on programme. Le plus important est de structurer son code, de le standardiser (appliquer des régles strictes, des conventions qui doivent principalement se baser sur les conventions de bases du système (OS, langage...)). Un bon programme possède un code source robuste, lisible et surtout facilement modifiable, adaptable.

Après un algorithme dépend du programme que l'on code. On ne va pas forcément chercher à obtenir un algo de recherche ayant la complexité la plus faible si cela est inutile.

Ce qui fait la différence entre un bon et un mauvais programme, c'est que le bon programmeur va appliquer naturellement des optimisations qui sont lisibles pour tous et qui surtout va utiliser des algorithmes adaptés à son programme.

Pour revenir un peu au sujet. Oui il faut impérativement (encore une fois selon mon avis) créer ou réutiliser une convention assez stricte d'écriture des programmes.
Je prend un exemple. En C++ il est bon d'appliquer des régles pour tout, l'indentation du code, la nomination des classes genre préfixées par Cl ou C ou se que l'on veut, les membres pareils, les parmaètres de fonctions, les constantes. De préférence développer des classes complètes si de base elles possèdent certains opérateurs (en gros ajouter (++, --, *, /, []...))...

Au fait, tu bosses toujours sur GFA Basic ?

J'ai la version 2 qui dort sur mon PC mais, malheureusement, à cause de mes études, je n'ai plus le temps de coder mes projets personnels.

Tu fais quoi de beau comme études ?

Euh Thibaut ce n'est pas le sujet du topic. (faut en ouvrir un autre là ^^)

Oui pardon. C'est fait dans jrad.

Je pense la post-incrémentation d'un pointeur pour accéder successivement aux champs d'une structure est une très bonne chose, tant que l'on commente chaque ligne (;accès au champ x).

./23> Voilà pourquoi je dis de toujours partir du principe qu'une fonction détruit %d0-%d2/%a0-%a1, pas plus ni moins.

./24 Ton exemple de définitions de champs vaut bien plus qu'un commentaire dans une structure.

Ouai mais voilà, ça l'empêche de faire de la post incrémentation lors de l'accès aux champs. Donc pas besoin de commentaires, en effet.
Mais dans ce cas, on obtient de l'ASM lent. Autant coder en C non ?

Mouai ça dépend. Si en effet c'est important dans une fonction critique alors là oui ok on se débrouille pour avoir le code le plus lisible, adaptable et rapide possible mais franchement dans 80% des cas ça sert à rien d'optimiser à l'extrême.

Bon c'est vrai on est sur TI, on a franchement la maladie de vouloir trop optimiser (genre optimiser l'affichage d'une image alors que par la suite on attend une pression d'une touche par l'utilisateur ).

Martial Demolins (./29) :

Kevin Kofler (./25) :
./23> Voilà pourquoi je dis de toujours partir du principe qu'une fonction détruit d0-d2/a0-a1 pas plus ni moins.

Hé, où sont partis mes signes '%'?