Înclure de l'asm dans du C :: 156éme edition - Page 2

-

bah, le move.l a0,a7 c pour faire une routine ki puisse clr des vbuffers... tu pass l'addr de l'écran dans a0
cad qu'avant d'appeler ta routine, si tu veux effacer scr_mem, tu fé lea $4c00,a0

sBibi
a écrit : et le principe n'est pas de moi...

En effet. Tu as pris la routine de ExtGraph, tu as rajouté l'utilisation de a7 (programmation sale!) et tu as déroulé la boucle.

Orion_ a écrit :
et p koi tu met -1, et pas 0

C'est une erreur.

-

-

-1.
C'est 0 qu'il faut mettre!

kevin>NON! je n'ai jamais vu les routines d'extgraph !!!

Ça explique pourquoi tu as mis la mauvaise valeur dans le moveq.
Mais c'est le même principe en tout cas.

la MAUVAISE valeur?? ptdr! pke il y a une bonne valeur a mettre??? n'importe koi... cette routine marche a merveille! t'as vraiment une mentalité de merde kevin... la j'en peux plus y a QUE tes méthodes qui sont "les bonnes" ça devient insupportable... sérieusement!

dans le forum asm, tu reproches a PpHd de suivre des idées toutes faites qu'il y a dans des "manuels" regarde toi un peu!

FIGHT !!!

excuse moi d'avoir parlé comme ça, mais la franchement ça devient tres lourd... mais très très très très lourd...

Il ne comprendra jamais le Kevin

Orion : si tu veux plus rapide que le memset que je t'ai codé à la page précédente, tu peux reprendre cette fonction de la bibliothèque Azur :

GX_clrscr:
; Code provenant de la bibliothèque Azur
; Optimisation : Julien Monville
 movem.l d3-d7/a2-a7,GXSvgReg
 move.l  4(a7),a7
 lea     3840(a7),a7
 moveq   #0,d0
 moveq   #0,d1
 moveq   #0,d2
 moveq   #0,d3
 moveq   #0,d4
 moveq   #0,d5
 moveq   #0,d6
 move.w  d0,a0
 move.w  d0,a1
 move.w  d0,a2
 move.w  d0,a3
 move.w  d0,a4
 move.w  d0,a5
 move.w  d0,a6
 moveq   #10,d7
GXCS_loop:
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 dbf     d7,GXCS_loop
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0-a6,-(a7)
 movem.l d0-d6/a0,-(a7)
 movem.l GXSvgReg(pc),d3-d7/a2-a7
 rts
GXSvgReg:
 ds.l    5+6

Le prototype : void GX_clrscr(void *plane)

sBibi
a écrit : la MAUVAISE valeur?? ptdr! pke il y a une bonne valeur a mettre??? n'importe koi... cette routine marche a merveille! t'as vraiment une mentalité de merde kevin... la j'en peux plus y a QUE tes méthodes qui sont "les bonnes" ça devient insupportable... sérieusement!

C'est la mauvaise valeur parce qu'il a demandé une routine pour effacer l'écran, pas pour le colorer en noir!

et alors? pour moi ça efface l'écran aussi...

et aussi ct pour qu'il aie a changer un truc, pas copier/coller dans sa source..
et prend la routine k'a filé tibo, c + court et je pense pas qu'un gain de qques dizaines de cycles t'apporte bcp...

"tu as rajouté l'utilisation de a7 (programmation sale!) "

pour moi, ce qui est sale, c'est les .s de tigcc...
et la encore c qui qui a décrété ke ct sale? c toi? on n'a pas les mêmes pts de vue alors..
et si ce n'est pas toi, bah applique a toi meme le discours ke t'as tenu a PpHd dans le forum assembleur...

je parle de ça:

"doit exclure le bas niveau d'une architecture."

Pourquoi? Parce que ton manuel le dit?

Bon OK, je vais me justifier alors: c'est sale, parce que tu risques d'avoir des ennuis avec des interruptions qui traffiquent usp.

Lesquelles ?

ui, leskelles?

Alors, lesquelles?

ben oui quoi, lesquelles ?

g entendu lesquelles ?

Aucune idée. Mais s'il n'y en a pas dans les AMS actuels, ça ne veut pas dire qu'il n'y en aura pas dans les AMS futurs.

Kevin Kofler
a écrit : Aucune idée. Mais s'il n'y en a pas dans les AMS actuels, ça ne veut pas dire qu'il n'y en aura pas dans les AMS futurs.

c sans importance alors, puisque de toutes manières ça ne te dérange pas de tout recompiler/réassembler à chaque fois (dsl mais la tentation était trop forte )

LOL

c'était un moment historique ça ... merci