Vous n'êtes pas identifié.
Je crois kon peut encore optimiser les fonctions graphiques en asm, cest ce ke je vais faire kan j'aurai le temps, je parle d'optmisation en terme d'accés mémoire (suspension du Pipeline).
Un jeu est en préparation !
@+
y@ss
Hors ligne
Ok ben c cool !!! Pa d'info + précise sur le jeu.. Sinon c koi ton pipeline ??
Hors ligne
je parle du Pipeline du processeur, au fait javais trouvé une comparaison interressante entre plusieurs processeurs de familles différentes, notez tt d'abord que le ARM est le model implanté sur la Game Boy Advance, le Z80 est le processeur de la TI et que le NecV30 Mx est celui de la Casio.
La comparaison est claire.
Enfin, CISC veut dire tt simplement Complex Instruction Set
et ques RISC veut dire Reduced Instruction Set.
Il y a une différence au niveau du jeux d'instructions et donc au niveau de la complexité matérielle est logique au niveau du Pipeline.
Notre machine n'est pas une machine de jeux comme l'est la GBA
regardez donc cett page pour voir la différence au niveau des MIPS:
http://www.ee.nec.de/Products/Asic/Syst … Index.html
Bye
Hors ligne
PS, c'est tests ont été effectués a l'aide du programme test Drhystone , ce ki veut dire qu'ils sont crédibles !
En ce qui concerne le Pipeline, ça fait partie de l'architecture du CPU, pour en savoir Plus, je te renvoie au lien suivant http://telnet7.tripod.com/articles/8086_achitecture.htm
Mais faut etre assez solide en architecture des Ordis pour comprendre ça :?
@+
Hors ligne
enfin le fichier pdf du V30Mx : http://www.ee.nec.de/_PDF/A14720EE1V0PL00.PDF
je fais un TPE sur la structure des processeurs, regarde la routine que j'ai fait pour l'ecran, je peut pas aller plus vite, chui desolé (en asm, c le maximum que je peut faire en pix par pix)
Hors ligne
Oui mais y@ss je ne vois pas comment on peut contrôler ce genre de chose en asm, c'est le fonctionnement interne du processeur, c'est utilisé par les programmes de manière "naturelle"... Et les dernières fonctions mises au point pour l'écran utilisent les instructions spéciales, de manipulation de bit du NECV30... Je ne vois vraiment pas comment on peut faire mieux ?
Hors ligne
If I understand correctly, you are trying to optimize your code..
maybe this is of some interest:
here are the instruction timings for the set1 instruction (on a necv20..)
r/m8, cl: 4/13
r/m8, i8: 5/14
r/m13, cl: 4/13
r/m16, i8: 5/14
as u can see, they should (in theory) be faster than the traditional move and shift
for general programming, I think following normal 286 optimization rules should help quite a bit:
-limit memory acces
-mind AGI stalls
-limit branching
-use string instructions
btw:
anyone know when the US forum will be up again?
Justement 2072,on ne peut pas utiliser les instructions spéciales a moins de créer un nouveau compilateur optmisé pour le NEC. je sais pas si Gcc incopore cette fonctionnalité.
les instructions de manipulations de Bits ne sont pas disponibles ss le 8086. mais jai trouvé un autre algo différent pour SetPix par exemple. il ets pas encore testé mais je pense kil est fonctionnel.
je le transcrirai ici cet aprem ou meme maintenant pk pas. comme ça vous me direz si ça marche.
alors javais 5 min de libre hier pis jai pensé à ça:
void pix (x, y) { push bx mov ax, x mov bx, y mov cx, ax and cx, 0x07 and ax, 0xFFF8 shl ax, 3 add ax, bx add ax, 0x1024 mov bl,1 shl bl, cl mov cl, [ax] or bl, cl mov [ax], bl pop bx }
Elle nest pas debuggé et sans commentaire (faut dire ke jai pas trop le temps). mais le squelette est la, ce qu'il ya de particulier cest kelle fait exactement :
* 6 acces mémoire dont la disposition est censée réduire au maximum les aléas de données au niveau du Pipeline excepté cette ligne qu'il est impossible de changer:
mov cl, [ax] or bl, cl
* 7 ALU (instructions logiques) qui prennent 1 cycle d'horloge * 2 instructions de transfert Reg- Reg ou Imm-Reg qui prennent 1 Cycle. Je pense que cest pas mal optmisé parce ken plus il nya pas de div ni de mul ki prennent plus de cycles et en meme temps blocke le pipeline parce kelles utilisent pendant approximativement 3 cycles les additionneurs et les Mux du process (ALU). ken pensez vous ? PS : J'espere ke les modérateurs deplaceront ce post vers Techniques de Programmations, PS2: j'édite encore une fois ce message pour dire que ça se peut que j'ai fait des erreurs de syntaxes, si cest le cas cest parce ke je suis pas habitué a programmer sur du 8086, mais plutot sur du 386 avec la norme AT&T sur Linux, cest bcp plus cool !! Il me faut donc une tres petite période d'aptation ... Merci :)
Hors ligne
des reactions ?
Hors ligne
* 7 ALU (instructions logiques) qui prennent 1 cycle d'horloge
* 2 instructions de transfert Reg- Reg ou Imm-Reg qui prennent 1 Cycle.
I'm not french speaking, so I've probably misunderstood you..
do you mean 1 ALU takes 1 cycle...
NONONO... not on this old cpu it doesn't..
the 'shift r, i' is specially costly, 5 + i clocks..
as for your code.. it's bugged
anyway.. u say u wanna write a compiler?
good luck man.. I'd rather stick to asm though
> BiTwhise: He didn't say he want to write a new compiler, he was just saying we need some new one to use specific instructions of v30mx processor...
( Welcome here! )
Hors ligne
Y@ss tu te plantes complètement ON PEUT UTILISER CES INSTRUCTIONS en les adressant directement par leur code en hexa:
void new_Whyp_Bpixel(int x, int y)//print a black pixel { asm { mov ax,segm_video //On met dans es le segment du buffer vidéo mov es,ax //on ne peut affecter directement es, on passe par ax mov bx,x // X représente l’abscisse mov si,y // Y l’ordonnée shl si,4 // Une ligne mesure 16 octet (128bit). si pointe vers la bonne ligne mov cl,bl // 0<=bx<128 Donc on peut manipuler bl au lieu de bx. // On place alors bl dans cl. shr bl,3 // Divise bl par 8. Le résultat est dans bl and cl,7 // On garde les 3 derniers bit de cl, c’est le reste de la division add si,bx // si pointe vers le bon octet (16*y+x) db 0x0F,0x14,0x0C7 // set1 bh,cl // Met à 1 le clieme bit de bh (qui était nul jusque la) or es:[si],bh // On place bh en mémoire vidéo en prenant soin de ne pas effacer les autres } }
Voilà ça c'est la fonction que j'utilise dans TOUCHE pour le mode vidéo 0xD3, elle a été inventé par Whyp et c'est la plus rapide qui puisse exister.
(segm_video doit contenir l'adresse du buffer vidéo)
sinon voici celle que j'utilise pour le mode normal:
void Whyp_Wpixel(int X,int Y) //Affiche un pixel blanc { asm { mov cx,X mov dx,Y mov es,segm_video mov si,dx push cx and cl,0xf8 // equivalent to cx - cx%8 (F8 = 11111000) shl cx,0x03 // (cx * 8) add si,cx pop cx and cl,0x07 //cl = cx%8 mov bl,0xFF db 0x0F,0x12,0x0C3 //clr1 bl,cl (specifique au nec v20/30) and es:[si],bl } }
btw: You can find it studying the NECV30 series technical info (I can send it to you).
But BitWise can you tell me more about this way of addressing instructions because in NEC documentation I can understand that for exemple in the last function 0x12 is the clr1 instructions but I have diffiulties to understand hhow you find the values for bl ans cl, I think bl is 0x0F and cl 0xC3 but I'm not sure of these deductions...
Hors ligne
Set1:
Physical Form: SET1 reg/mem8,CL
COP (Code of Operation) : 0FH 14H Postbyte
Physical Form: SET1 reg/mem8,imm8
COP (Code of Operation) : 0FH 1CH Postbyte imm8
Physical Form: SET1 reg/mem16,CL
COP (Code of Operation) : 0FH 15H Postbyte
Physical Form: SET1 reg/mem16,imm8
COP (Code of Operation) : 0FH 1DH Postbyte imm8
Not1:
Physical Form: NOT1 reg/mem8,CL
COP (Code of Operation) : 0FH 16H Postbyte
Physical Form: NOT1 reg/mem8,imm8
COP (Code of Operation) : 0FH 1EH Postbyte imm8
Physical Form: NOT1 reg/mem16,CL
COP (Code of Operation) : 0FH 17H Postbyte
Physical Form: NOT1 reg/mem16,imm8
COP (Code of Operation) : 0FH 1FH Postbyte imm8
Clr1:
Physical Form: CLEAR1 reg/mem8,CL
COP (Code of Operation) : 0FH 12H Postbyte
Physical Form: CLEAR1 reg/mem8,imm8
COP (Code of Operation) : 0FH 1AH Postbyte imm8
Physical Form: CLEAR1 reg/mem16,CL
COP (Code of Operation) : 0FH 13H Postbyte
Physical Form: CLEAR1 reg/mem16,imm8
COP (Code of Operation) : 0FH 1BH Postbyte imm8
Test1:
Physical Form: TEST1 reg/mem8,CL
COP (Code of Operation) : 0FH 10H Postbyte
Physical Form: TEST1 reg/mem8,imm8
COP (Code of Operation) : 0FH 18H Postbyte imm8
Physical Form: TEST1 reg/mem16,CL
COP (Code of Operation) : 0FH 11H Postbyte
Physical Form: TEST1 reg/mem16,imm8
COP (Code of Operation) : 0FH 19H Postbyte imm8
I don't know the different postbytes for the different registers right now, but I'm sure you could find it on the internet
All remember is, they are not in the expected order (ax, bx, cx, dx...) but something like (dx, bx, cx, ax... don't remember really)
Just experiment and you'll find out...
make some selfmanipulative code, and you'd be able to map it out quite quickly
btw, there are some more nec specific instruction, and the option to go into native mode (instead of 8086 mode), but I haven't had time to explore this
OK thank you, what are the advantages of native mode ?
Hors ligne
sorry about that...
ignore last sentence,
what I meant to say..
You can break out to 8080 emulation mode
8086 is native mode.. as I explained, I made a mistake... you can brake from native mode to 8080 mode... is you want to :?
anyway:
Format of Postbyte:
MM RRR MMM
MM - Memory addresing mode
RRR - Register operand address
MMM - Memory operand address
RRR Register Names
Fields 8bit 16bit 32bit
000 AL AX EAX
001 CL CX ECX
010 DL DX EDX
011 BL BX EBX
100 AH SP ESP
101 CH BP EBP
110 DH SI ESI
111 BH DI EDI
I don't feel like filling in more here... but if you want I can send you my source document
a 2072: ok !, je savais pas du tt, en fait je voulais justement demander ce que faisait db .... Dans ce cas c excellent j'ai rien a dire !
BitWhise: Please Send me your source document, and be Welcome !
@+
Hors ligne
Yes send me your source document thanx !
Hors ligne
BitWhise: Please Send me your source document, and be Welcome !
sure.. if you could give me your e-mail address...
2072: have mailed it to you now
:arrow: yass008@hotmail.com
Hors ligne