Effacer une zone de mémoire. - Page 1

Je possède un espace mémoire de 103 octets et le problème c'est que je cherche un algo le plus petit possible capable d'effacer cette zone de 103 octets.

Donc j'ai appliqué cette méthode:

       moveq #25,d0    ;25 car (103/4)-1
       lea      debut_table(PC),a0
_loop:
       clr.l      (an)+
       dbf       d0,_loop

Je pense qu'il me reste 1 octet à vider à la fin mais je ne suis pas sûr qu'après:
clr.b (a0) suffit.

Ensuite je connais dbf mais je voudrais plus de détails sur cette fonction et surtout si comparé à dbra elle est plus puissante et rapide, car comme vous le savais certaines instructions sont des synonyme comme dbra et bien d'autres.

Je ne cherche pas la vitesse ici mais plutôt une fonction la plus compacte possible, dans le cas d'effacer une plus grande zone mémoire, comment procéder?

Pour divers raisons, il m'est presque impossible de tester cette fonction et de savoir parfaitement son comportement.

dbf = dbra.
Je crois que dbra n'existe pas, la vraie mnémonique est dbf.

clr.b (a0)

Pour faire petit :    moveq.l #103/2-1,d0
    lea.l   debut_table(pc),a0
loop:
    clr.w   (a0)+
    dbf     d0,loop

Je suis très bête
b (a0)+ dbf d0,loop

Pour faire encore plus petit :    moveq.l #103-1,d0
    lea.l   debut_table(pc),a0
loop:
    clr.

Elle où la différence ? (à part que c'est plus lent )

Sinon si tu veux un truc un peu plus compact, tu peux le faire octet par octet. Après c'est difficile de faire mieux, sauf qu'en général tu peux éviter le lea qui se trouve au début si tu as initialisé juste avant la variable qui se trouvait juste avant

Ou encore, pour faire compact et rapide, si tu peux allouer une mémoire de 106 octets, tu peux effacer la zone de 106 octets long par long...

Oups post croisé

Merci, je vais modifier mon code, j'avais un doute là dessus.

Pollux :
Elle où la différence ? (à part que c'est plus lent )

En fait, avec sa technique, il restait 3 octets à effacer, donc il aurait du faire un clr.w puis un clr.b.

Au passage 106 n'est pas divisible par 4, il devrait utilier une zone de 104 octets plutôt.

Au passage vite fait une question:
Pour modifier la table d'interruptions vectorielle, est-ce que je suis obligé de désactiver toutes les interruptions avec:
move.w #$0700,d0
trap #1

Puis les réactiver avec bien sûr
move.w #$0000,d0
trap #1

Oui oui. Je pensais que geogeo ne s'était pas trompé et que 103 = 4*x+1 (mais évidemment en fait 103=4*25+3). Et effectivement comme en plus le compilo va peut-etre générer du padding s'il déclare un int juste après, 104 octets n'est pas tellement plus cher...

geogeo> non, tant que tu ne la copie bien long par long et que tu es sur que le déclenchement d'une interruption ne crasherait pas (i.e. pas de données non initialisées...)

mais évidemment en fait 103=4*25+3

Oui en effet, j'avais oublié qu'il fallait que j'efface un word et un byte à la fin.

geogeo> non, tant que tu ne la copie bien long par long et que tu es sur que le déclenchement d'une interruption ne crasherait pas (i.e. pas de données non initialisées...)

Ce que j'ai assez peur c'est que je modifie le port .0x600015 et 0x600017 ainsi que bien sûr l'adresse de l'interruption et j'ai pas envie que ça produise des crashs innattendu, j'ai envie d'être sûr à 100%.

Ben tu changes d'abord ton interruptions puis tu initialises les 2 ports I/O, non?

D'accord, je vais voir ça.

geogeo :
Au passage vite fait une question:
Pour modifier la table d'interruptions vectorielle, est-ce que je suis obligé de désactiver toutes les interruptions avec:
move.w #$0700,d0
trap #1

Puis les réactiver avec bien sûr
move.w #$0000,d0 trap #1

Je pense que ce ne soit pas la peine. En tout cas, pas grand monde le fait, et ça n'a jamais posé problème.

Ca vaut la peine si tu modifie plusieurs tables d'interruptions qui sont inter-dependantes.

Ca vaut la peine si tu modifie plusieurs tables d'interruptions qui sont inter-dependantes.

En effet c'est pour ça que j'ai posé cette question.

Comme vous le savez je veux que cette librairie ne créer pas d'inconvénient avec les programmes l'utilisant donc ici je pense retirer les instructions trap #1 pour éviter des problèmes de programmes bidouilliant sur les interruptions.

Pas besoin tu fais:

move.w #$0700,d0
trap #1
move.l #NewHandler,$400064
move.l #NEwHandle,...
move.l #
trap #1

N'oublie pas que le trap #1 te renvoie l'ancienne valeur du niveau courant des auto-ints. Il suffit de le rappeller avec pour revenir a celles avant.

Je les ai enlevé et ça fonctionne très bien.
Merci pour ce conseil mais le dernier appel à trap #1 dans ton exemple n'exige pas que d0 soit à 0?

Non. Relis la fin du post de PpHd...

Ah ouai d'accord, merci Jackiechan, j'avais pas fait gaffe à ça.