Ruby ?? - Page 2

De plus, si leurs nombres sont signés, le compilateur ne peut pas faire cette optimisation, à cause de la sémantique bizarre de % pour les nombres négatifs en C.

Quelle est cette sémantique ?

squalyl (./30) :
parce que c'est facile d'attendre que le compilo remplace un mod 16 par un &0xf quand on pourrait le faire soi même?
bref, le mauvais est encore une fois entre la chaise et le clavier je pense.

Je ne suis pas d'accord. Quand on veut coder de façon claire, lisible par autrui, et logique, on utilise un modulo. Le masquage est une conséquence de la base utilisée mais n'exprime pas directement un modulo. Quand le compilateur est bon, il se charge de convertir le modulo en un masquage quand c'est possible. Les langages de haut niveau permettent plus de lisibilité, il faut en profiter.

Je doute que la règle dans une équipe d'ingénieurs soit d'obscurcir le code.

Thibaut (./32) :
Quelle est cette sémantique ?

Le résultat est négatif pour x%y avec x négatif et y positif.

Donc un neg suivi d'un and et suivit à nouveau d'un neg suffit ? (14 cycles en gros)

Non, parce qu'il faut tester les combinaisons de signe aussi. Le code généré par GCC en -O2 est assez complexe, en -Os, il ne va pas se casser la tête et générer un divs + swap (c'est plus court). Donc il faut toujours écrire &15 si c'est ce qu'on veut dire. Ou alors toujours utiliser des nombres non signés quand c'est possible. (AMHA, c'est une erreur d'utiliser un nombre signé quand on sait qu'un nombre ne peut jamais être strictement négatif, ça empêche/complique les optimisations des divisions/modulos par des puissances de 2 et ça crée aussi des problèmes avec le débordement des nombres signés qui n'est pas défini en C.)

C'est divs+swap, mais seulement si la plage des valeurs le permet
Là, pour écrire un %lX, vcbprintf appelle la routine de division/modulo 32 bits par 32 bits...

Sauf qu'à mon avis, chez TI comme partout ailleurs (sauf dans des conditions particulières) ils ont cherché à priviliégier la lisibilité du code pour qu'il soit testable, vérifiable et maintenable, plutôt que la performance qui pousse souvent à faire des bouts de code assez acrobatiques. Pedrom par exemple, écrit tout en assembleur (ou presque ? peu importe) et probablement bien optimisé, n'aurait eu aucun avenir au niveau industriel.
Donc peut-être qu'ils auraient pu faire mieux, mais c'est pas forcément si évident que ça de leur jeter des pierres

Ximoon

Il y a un truc qu'il ne faut pas perdre de vue avec cette nouvelle calc :
On passe de quelques Ko de ram a plusieurs Mo

Donc les objectifs ne sont pas les memes chez TI c'est sûr...

PedroM n'est surtout carrément pas maintenable en son état actuel, tout dépend de tout, les fonctions s'attendent à ce que d'autres fonctions (souvent même pas dans le même fichier .asm!) soient à moins de x octets de distance (parfois x=127 ) (ça marche parce que tous les .asm sont inclus dans le même gros .asm ), elles s'appellent par des points d'entrée "raccourci" pour contourner la convention d'appel standard, bref ce n'est pratiquement pas modulaire. (Et c'est bien dommage, j'aurais bien voulu faire des modifications, mais c'est la galère de changer quoi que ce soit vu sa structure imbitable.)

Thibaut(./36) :
Je ne suis pas d'accord. Quand on veut coder de façon claire, lisible par autrui, et logique, on utilise un modulo. Le masquage est une conséquence de la base utilisée mais n'exprime pas directement un modulo.

(vus que je découvre ce masque )

./39 > CQFD

./40> Contre. J'écris aussi <<3 quand je veux multiplier par 8.

Thibaut (./32) :
Je ne suis pas d'accord. Quand on veut coder de façon claire, lisible par autrui, et logique, on utilise un modulo. Le masquage est une conséquence de la base utilisée mais n'exprime pas directement un modulo. Quand le compilateur est bon, il se charge de convertir le modulo en un masquage quand c'est possible. Les langages de haut niveau permettent plus de lisibilité, il faut en profiter.

Tout dépend du choix qu'on veut faire entre expressivité et performance, parfois ce n'est pas compatible.
Mais avec du petit matos comme des calcs, TI a pas forcément fait le meilleur choix.

Pour le compilo, le choix a été fait en amont, c'est au développement de s'adapter ensuite, on peut pas ensuite ramener tous les problèmes au compilo.

./26 > Ouais, mais je pense que l'utilisation que l'on a fait de notre TI dépasse la charge prévue par les fonctions codées par TI (genre le coup de bubllesort pour les icônes du menu).

./44 > Contre. J'écris *8.

Kevin Kofler (./42) :
./40> Contre. J'écris aussi <<3 quand je veux multiplier par 8.

Yep, celui là je le connais.

Kevin Kofler (./39) :
PedroM n'est surtout carrément pas maintenable en son état actuel, tout dépend de tout, les fonctions s'attendent à ce que d'autres fonctions (souvent même pas dans le même fichier .asm!) soient à moins de x octets de distance (parfois x=127 ) (ça marche parce que tous les .asm sont inclus dans le même gros .asm ), elles s'appellent par des points d'entrée "raccourci" pour contourner la convention d'appel standard, bref ce n'est pratiquement pas modulaire. (Et c'est bien dommage, j'aurais bien voulu faire des modifications, mais c'est la galère de changer quoi que ce soit vu sa structure imbitable.)

Ben oui. Et alors ? Je ne vois pas en regard de tes arguments la logique qui le rend inmaintenable ?
CF (la béta sortie) était inmaintenable. Je connais la différence.

Pour la taille des appels, remplace tous les bsr par jsr, les bra par jmp, laisse le linkeur optimisé et on n'en parle plus. Les points d'entrées raccourcis ne sont pas très compliqués à utiliser, et de toute facon tu n'es pas obbligé de les utiliser.

Sinon, perso je laisse le compilateur optimisé *8, mod 8, tout seul. S'il n'est pas capable d'optimiser çà, il est nul et ca ne vaut pas la peine que j'essaye de faire un code rapide avec.

Il y a des bCC entre fonctions aussi.

ExtendeD (./43) :
Pour le compilo, le choix a été fait en amont, c'est au développement de s'adapter ensuite, on peut pas ensuite ramener tous les problèmes au compilo.

Sauf que tu as oublié de préciser que le code généré était de pire en pire à chaque nouvelle version de la ROM de TI.
Les ROMS des premières 92 avaient du code assembleur généré raisonnable.

PpHd (./48) :
Sinon, perso je laisse le compilateur optimisé *8, mod 8, tout seul. S'il n'est pas capable d'optimiser çà, il est nul et ca ne vaut pas la peine que j'essaye de faire un code rapide avec.

Une fois de plus, pour les nombres signés, ce n'est pas équivalent (sauf pour la multiplication), de plus la sémantique de >>3 et &7 est celle que tu veux en général pour la manipulation de sprites, celle de /8 et %8 non. (J'en ai corrigés, des bogues, dans des morceaux de code postés sur les forums, en remplaçant /8 et %8 par >>3 et &7 respectivement pour des nombres signés!)

Kevin Kofler (./49) :
Il y a des bCC entre fonctions aussi.

Parce que c'est un ensemble de fonction liées. Je ne m'amuse pas à le faire entre .asm ce genre de saut

Kevin Kofler (./51) :
Une fois de plus, pour les nombres signés, ce n'est pas équivalent (sauf pour la multiplication), de plus la sémantique de >>3 et &7 est celle que tu veux en général pour la manipulation de sprites, celle de /8 et %8 non. (J'en ai corrigés, des bogues, dans des morceaux de code postés sur les forums, en remplaçant /8 et %8 par >>3 et &7 respectivement pour des nombres signés!)

Sauf que j'utilise dans ce cas des nombres non signés. J'essaye d'écrire du code optimum pour le compilateur de telle sorte qu'il est le maximum d'info pour optimiser.

Martial Demolins (./53) :
Et tu fais comment s'il optimise ton futur smc?

Je ne fais pas de SMC en C. Faut être maso pour en faire.

PpHd (./54) :
Sauf que j'utilise dans ce cas des nombres non signés. J'essaye d'écrire du code optimum pour le compilateur de telle sorte qu'il est le maximum d'info pour optimiser.

Et tu fais comment si tu as besoin de clipping à gauche? Les coordonnées d'un sprite clippé peuvent être légitimement négatives.

Kevin Kofler (./56) :
Et tu fais comment si tu as besoin de clipping à gauche? Les coordonnées d'un sprite clippé peuvent être légitimement négatives.

Je fais pas de division par 8 avant de faire le test de clipping. Après, je convertis en non signé.

[sondage=15976]

a<<=3; évidemment => je ne peux pas voter.

Ça dépend dans quel contexte :
Si c'est de la manipulation binaire : a <<8.
Si c'est de l'arithmétique, a*8.

Quant à a<<=8... J'ai dû le faire parfois, mais franchement c'est illisible...