@thellier Oui, ça ne changerait pas l'assembleur, c'est juste que je trouve que :

pix.r = 0x66;  ou pix.red = 0x66;

est plus lisible que :

pix.B.ARGB[1] = 0x66;


A propos d'assembleur, avec des processeurs comme le PowerPC (et ses instructions de type "rotate left and mask") si tu manipules la valeur 32 bits (qui est dans un registre du CPU) alors lire ou écrire une des composantes ne prendra qu'un seul cycle.

Soir'
>Et lire la composante rouge avec : pixel.r
Oui tout à fait meme si au final ça changera rien sur l'ASM généré

>une division par 2 alors qu'une multiplication par 0.5 c'est plus rapide
a) le >>1 est plus rapide qu'un (vrai) /2

b) ici c'est des entiers (UBYTE = unsigned byte = entier 8 bits signé) donc pas possible de faire * 0.5 avec un nombre sans virgule
Sauf si on le convertit mais là on perd notre optimisation

>Ton code me paraissait faux à cause [...] tableau non initialisé.

Il est vrai qu'il est pas intialisé mais bon si j'écrivais tout le code pour récupérer un pointeur sur les pixels de l'écran proprement depuis le système .... on serait pas rendu :-P
C'est un exemple abstrait

>car non déclaré comme pointeur sur un tableau.

Je le redis une fois de plus "en C un pointeur et un tableau à une dimension sont fondamentalement la meme chose lors de leur utilisation"
Si vous avez appris qque chose de différent à la fac alors votre prof parlait sans comprendre l'ASM ;-P

Ainsi pt[0].ARGB32 et pt->ARGB32 sont en fait la meme chose une fois compilee
Une fois assimilée ceci n'importe qui peut comprendre ce qu'est un pointeur


Alain

Même si on mettait "/ 2", le compilateur génèrerait un shift de 1 bit.
Message édité par : corto / 19-01-2017 17:24

Si je ne dit pas de bétise, l'opérateur >> correspond à un décalage de bit, c'est une autre façon de faire une division et il s'agit à ma connaissance de méthode la plus rapide pour faire une division.

merci de me corriger si je me trompe :)

Sinirus,
En fait ce n'est pas considéré comme une divsion mais un décalage de bits beaucoup plus rapide qu'une multiplication.
C'est pourquoi tu vois dans les sources des lignes comme a>>4 plutôt que a/16.

Alain,
Ton code me paraissait faux à cause de pt[n], car non déclaré comme pointeur sur un tableau et non initialisé.
D'après ce que tu as écrit, le compilateur compile comme tu le veux mais le fera-t'il à chaque fois indépendamment du compilateur et/ou de sa version?

@Thellier

Pourquoi faire une division par 2 alors qu'une multiplication par 0.5 c'est plus rapide (les divisions sont à évité le plus possible)

Super intéressant !!!

Merci pour cette manip !!

Ooouuups tu as tout a fait raison c'étais un >> (une division par 2) que je voulais mettre et non pas un >

L'idée c'est additionner les 2 couleurs (de valeur entre 0 et 255) puis diviser par 2 pour retomber sur une valeur entre 0 et 255 qui tienne à nouveau dans un UBYTE

Au final on a juste une lecture 32bits et une écriture 32 bits à la fin et les autres opérations entre ces deux accès se font sur les registres sans accès mémoire

A noter l'utilisation du pointeur "comme un tableau" en faisant pt[n]. dont on peut espérer que la conversion en assembleur (la compilation quoi) donnera un accès 32 bits indexé par un registre 

du genre

pix.L.ARGB32=pt[n].L.ARGB32;

qui donnerait  en 68000

MOVE.L D1, $0(A1, D0.L)  

ou un truc similaire en PPC

Alain