Discussion: [Projet] PatrickBoy
Afficher un message
Vieux 13/06/2009, 17h19   #6
Brunni
Super Modérateur
 
Date d'inscription: 10/11/2005
Localisation: Un pays avec beaucoup de banques
Messages: 3 226
Par défaut

Le but c'était d'être minimal, dans l'esprit RISC. Si j'avais vraiment voulu coder 40000 opcodes je me serais attelé à émuler un 68k par exemple
En fait si tu regardes le jeu d'instruction y a pas besoin d'aller si loin, déjà rien que faire un masque c'est compliqué:
Code:
   ; branche à bitset si r0 & 0x100 (bit 8) sans modifier r0
    mov r2, r0     ; copie de r0
    mov r1, 1
    shl r1, 8      ; r1 = 1 << 8
    and r2, r1
    bnz r2, :bitset
Besoin de 2 registres temporaires et 5 instructions...
Dans d'autres CPUs on a inclus des instructions bittest par exemple pour éviter justement ces problèmes. Mais c'est là qu'on voit la magie de ce que sait faire l'ARM, où ça donnerait:
Code:
    ands r2, r0, #0x100    ; codage constante 8 bits + décalage 5 bits (imm8m)
    bne bitset
Bon en même temps l'ARM est un jeu d'instructions 32 bits donc t'as plus de libertés, mais il est tout simplement bien pensé, mais complexe à implémenter. Le thumb (16 bits) lui est super impressionnant mais toujours aussi compact, et ça pour émuler (décoder les opérandes) c'est très lent. Un Z80 (CISC) par exemple est un bonheur en comparaison, tu lis un octet ça te dit quelle instruction c'est (donc une simple table de saut de 256 entrées pour décoder). Ensuite les opérandes éventuelles sont des octets supplémentaires.
Brunni est déconnecté   Réponse avec citation