[Mollusk]

Ca change probablement rien, mais tu as testé avec un truc dans ce genre :

Code

 (c):
u32 *ptr = &TabPoints[GateArray.scr_mode][ 0 ][0];
u8 *src0 = &TabPointsDef[GateArray.scr_mode][ 0 ][0];
i = 256;
while (i--) 
{
	*ptr++ = GateArray.palette[ *src0] | GateArray.palette[ *(src0 + 1)] | GateArray.palette[ *(src0 + 2)] | GateArray.palette[ *(src0 + 3)]
	src0 += 4;
}

Et sinon, ça me fait beaucoup penser au code de fire qu'on a cherché à optimiser dans un autre thread

Edit : j'ai corrigé mon code (je crois) et du coup je comprends mieux la lenteur...

[Alekmaul]

sauf que ton code me semble pas correct coté src0 car l'indirection change suivant TabPointDef et donc palette ne pointera pas forcement sur la même donnée ...

[Alekmaul]

Double post pour dire "honte à moi", "shame on me" 

J'appelle ce code uniquement si un flag est à 1, un flag nommé UpdateLink et à la fin de mon code en assembleur, je faisais :

  mov   r2, #0
   str   r2, UpdateInk_local

à la place de

  ldr r3, UpdateInk_local
  mov   r2, #0
   str   r2, [r3, #0]

bref, je tapais pas au bon endroit  !!!
maintenant, je suis à 80% avec le code assembleur, reste plus qu'à trouver le pb de différence d'affichage

Le nouveau code complet cette fois ci :

    .align   2

    .section   .itcm,"ax",%progbits

    .global CalcPointsArm
    .type   CalcPoints, %function
 
    .extern TabPoints
    .extern TabPointsDef
    .extern UpdateInk
    .extern GateArray
   
;@ --------------------------- Entry point --------------------------
CalcPointsArm:
  ;@ r0 = pointer to GateArray.palette
  ;@ r1 = GateArray.scr_mode
  ;@#########################################   
  stmfd   sp!, {r4, r5, r6, r7,r8,lr}
 
  ldr r0,GAscr_mode_local
  ldr r1,[r0]
  ldr r0,GApalette_local
 
  mov r2,#255                     ;@  for (i=0;i<256;i++)
 
  ldr r3,TabPointsDef_local
  add r3,r3,r1,lsl #10            ;@ TabPointsDef+mode*256*4
 
  ldr r4,TabPoints_local
  add r4,r4,r1,lsl #10            ;@ TabPoints+mode*256*4

modpalCPA:
  ldr r6,[r3],#-4                  ;@ TabPointsDef[GateArray.scr_mode][ i ][ 0 ]
  ldr r5,[r0,r6,lsr #24]          ;@ GateArray.palette[
 
  lsl r6,r6,#8                    ;@ TabPointsDef[GateArray.scr_mode][ i ][1]
  ldr r7,[r0,r6,lsr #24]          ;@ GateArray.palette[ << 8
  orr r5,r5,r7,lsl #8             ;@
 
  lsl r6,r6,#8                    ;@ TabPointsDef[GateArray.scr_mode][ i ][2]
  ldr r7,[r0,r6,lsr #24]          ;@ GateArray.palette[ << 16
  orr r5,r5,r7,lsl #16            ;@ 
 
  lsl r6,r6,#8                    ;@ TabPointsDef[GateArray.scr_mode][ i ][3]
  ldr r7,[r0,r6,lsr #24]          ;@ GateArray.palette[ << 24
  orr r5,r5,r7,lsl #24            ;@ 
 
  str r5,[r4,r2,lsl#2]            ;@ *(u32*)(&TabPoints[GateArray.scr_mode][ i ][ 0 ]) = ...
 
  subs r2,r2,#1                    ;@ fin de for (i=0;i<256;i++)
  bne modpalCPA
     
  ldr r3, UpdateInk_local
  mov   r2, #0
   str   r2, [r3, #0]
 
  ldmfd   sp!, {r4, r5, r6, r7, r8, pc}

TabPoints_local:     .word TabPoints
TabPointsDef_local:  .word TabPointsDef
UpdateInk_local:     .word UpdateInk
GAscr_mode_local:    .word GateArray+4
GApalette_local:     .word GateArray+32

[Copper]

hum les orr.l du début (avant modpalCPA:) me semblent bizarres quand même tu n'aurais pas fait un chercher / remplacer un peu trop rapide ?

[Alekmaul]

nan, j'ai rechangé maintenant avec des add, même top, effectivement, j'avais vu le pb

je viens de mettre à jour le post pour ne plus les avoir

[EDIT] Pb trouvé, on adressait pas en 32 bit la palette via GApalette_local, maintenant tout est ok, je posterais plus tard le code actuel au cas où quelqu'un se dit qu'une optimisaiton serait encore possible

[mikegba]

Alek, question à la con , quand tu fais ça :

ldr r7,[r0,r6,lsr #24]          ;@ GateArray.palette[ << 8


ton but c'est de charger des données 8 bits ou 32 ??

Ce que je veux dire, tu attends dans r7 une donnée sur 8 ou 32 bits ?

[Alekmaul]

héhé, bravo Mike , grilled sur ce coup

Code actuel un peu sale que je pense optimiser :

modpalCPA:
  ldr r6,[r3],#4                  ;@ TabPointsDef[GateArray.scr_mode][ i ][ 0 ]
  mov r8, r6, lsl #26
  ldr r5,[r0,r8,lsr #24]          ;@ GateArray.palette[
 
  mov r8, r6, lsl #18
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 8
  orr r5,r5,r7,lsl #8             ;@
 
  mov r8, r6, lsl #10
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 16
  orr r5,r5,r7,lsl #16             ;@ 
 
  mov r8,r6, lsl #2
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 24
  orr r5,r5,r7,lsl #24             ;@ 
 
  str r5,[r4,r2,lsl#2]            ;@ *(u32*)(&TabPoints[GateArray.scr_mode][ i ][ 0 ]) = ...
 
  add r2,r2,#1                    ;@ fin de for (i=0;i<256;i++)
  cmp r2,#256
  bne modpalCPA

[Copper]

Donc là le code fonctionne...

Par contre je comprend pas pourquoi tu veux pas inverser la boucle pour aller de 255 à 0 pour gagner une instruction de test...

[mikegba]

après pour les dernières optimisations, si on ne touche pas la structure des données, il reste le débouclage ( ça ça gagne pas mal ) et comme on disait au début compter de 256 à 0

[Alekmaul]

oui, mais si je compte de 255 à 0 , comme je fais pour gérer le 0 ?
car le bne va stopper sur le 0, donc , je dois traiter ce dernier en plus ?
Pour le "débouclage", t'as des infos  ?

[mikegba]

si tu considère que quand r2=0, la boucle doit encore être exécutée, alors au lieu de brancher avec un bne, tu branche avec un bpl ( branche si positif )

[mikegba]

pour le débouclage, si on considere qu'on déroule que 2 fois , ça donnerait un truc du genre:


modpalCPA:
  ldr r6,[r3],#-4                  ;@ TabPointsDef[GateArray.scr_mode][ i ][ 0 ]
  mov r8, r6, lsl #26
  ldr r5,[r0,r8,lsr #24]          ;@ GateArray.palette[
 
  mov r8, r6, lsl #18
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 8
  orr r5,r5,r7,lsl #8             ;@
 
  mov r8, r6, lsl #10
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 16
  orr r5,r5,r7,lsl #16             ;@
 
  mov r8,r6, lsl #2
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 24
  orr r5,r5,r7,lsl #24             ;@
 
  str r5,[r4,r2,lsl#2]            ;@ *(u32*)(&TabPoints[GateArray.scr_mode][ i ][ 0 ]) = ...

  sub r2,r2,#1

  ldr r6,[r3],#-4                  ;@ TabPointsDef[GateArray.scr_mode][ i ][ 0 ]
  mov r8, r6, lsl #26
  ldr r5,[r0,r8,lsr #24]          ;@ GateArray.palette[
 
  mov r8, r6, lsl #18
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 8
  orr r5,r5,r7,lsl #8             ;@
 
  mov r8, r6, lsl #10
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 16
  orr r5,r5,r7,lsl #16             ;@
 
  mov r8,r6, lsl #2
  ldr r7,[r0,r8,lsr #24]          ;@ GateArray.palette[ << 24
  orr r5,r5,r7,lsl #24             ;@
 
  str r5,[r4,r2,lsl#2]            ;@ *(u32*)(&TabPoints[GateArray.scr_mode][ i ][ 0 ]) = ...

  subs r2,r2,#1                    ;@ fin de for (i=0;i<256;i++)
  bpl modpalCPA

[Copper]

Ben en fait tu peux aller de 256 à 1 par exemple

Le débouclage c'est par exemple de dupliquer 256 fois le code plutot que de faire une boucle

On peut aussi faire du débouclage partiel par exemple exécuter 16 fois le code 16 fois dupliqué...

Ca permet d'économiser des sub / bne

Ca peut être intéressant dans un cas de figure ou tu es presque à 60 fps avec une boucle classique... et quand le nombre d'instructions dans la boucle est très réduit (genre une copie de buffer)

Grillé

Bon par contre tu peux supprimer un sub r2,r2,#1

[Alekmaul]

Merci mikegba, tu seras toujours un dieu de l'assembleur pour moi (au même titre que Flubba ).
J'intègre tout cela dans l'émulateur.
Pour info, c'est bien entendu pour la version 3.0 de l'émulateur Amstrad AmeDS, qui sera donc FullSpeed normalement quelque soit le mode graphique

Et merci aussi à Copper, je ne t'oublies pas of course

[Alekmaul]

Bon par contre tu peux supprimer un sub r2,r2,#1

Ah, alors, je vois pas, on doit bien passer d'une valeur à une autre pour le dédoublage non  ?