49Fermer51
BrunniLe 27/05/2009 à 21:32
Sympa, je pensais pas que GCC utilisait Bison sorry
./46 Cool, je pensais pas qu'on pouvait faire si simple. J'ai dû en faire pour Bison dans le cadre du cours (le 3ème labo voulait qu'on refasse le lexer et la grammaire avec Lex + Bison) elle ne gère pas la priorité et l'associativité correctement ^^
Folco (./40) :
Brunni (./38) :
Déjà il y a pour 14 bits d'opérande (sur 16), donc seulement 3 pour l'offset de branchement

Ben je comprends que ton proc ait des problèmes d'orthogonalité. tripo

Je suis passé à 4 bits #modlove#
(pour info j'ai splitté en 2 instructions: b[eq|ne|lt|gt] ra, rb, c(4 bits) avec remplacement de a >= b par b < a, et b[z|nz] ra, c(8 bits) en plus du branchement inconditionnel avec constante 8 bits ou registre, soit qd même 4 opcodes de saut...)
Au total je m'en suis sorti avec 30 opcodes. J'ai implémenté une partie du GPU (le mode bitmap 8 bits, et les BGs du mode texte 4 bits), me reste à faire les sprites et le mode bitmap 4 bits. J'ai implémenté le DMA, les IRQ, d'ailleurs encore une fois c'est super vicieux ces pseudo instructions. Prenons un exemple simple qui fait un petit dégradé de couleur:
$main
	mov r0, :irqHandler
	st  r0, IRQHANDLER
	mov r0, (IRQ_HBLANK | IRQ_MASTER)
	st  r0, IRQE
	b   -1            ; boucle infinie

:irqHandler
	push r0
	ld8 r0, DISPSTAT  ; scanline
	st  r0, PALETTE
	pop r0
	ReturnFromIrq

Tout a l'air ok: je sauve et restaure r0 que je modifie dans le handler. Mais en fait il y a le registre 'tmp' utilisé par les pseudo instructions (par exemple st r0, PALETTE fait mov tmp, PALETTE puis st r0, [tmp]), et si tu oublies de le sauver -> paf!
En tous cas c'est très intéressant et j'ai bcp appris. Mais je vais pas tellement aller plus loin je pense, ça prend bcp de temps. Je ferai ptet un topic si ça intéresse du monde.