Sympa, je pensais pas que GCC utilisait Bison
./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é. 
Je suis passé à 4 bits

(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.