30

Pourquoi n'as-tu pas utilisé Bison?
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

31

Parce que pour apprendre/comprendre ce qui se passe vraiment c'est bien de mettre la main à la pâte. Là je regardais aussi le fait que j'ai codé des listes chaînées à la main plutôt qu'utiliser la STL.

Maintenant si je devais tout recommencer de zéro, j'utiliserais un max d'outil, la phase d'apprentissage est terminée (même si je me souviens plus trop des détails maintenant ça commence à dater).
Tout ce qui passe pas par le port 80, c'est de la triche.

32

./27 : putain quelle horreur grin

théoriquement l'avantage d'écrire un parseur à la main, c'est d'avoir un code petit et lisible... grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

33

En effet, comme le dit Kevin le but de mon parseur c'est d'être simple. Quand je voudrai aller plus loin et faire un "vrai" langage j'utiliserai yacc ou autre smile
Sinon merci Zeph, je pense qu'effectivement je me complique la vie tongue Pour ma façon de faire chaque fonction (représentant une règle de production) reçoit un arbre (AST) auquel elle doit attacher le sous arbre produit. Lit permet d'obtenir le prochain jeton. Pour l'expression:
// [OP_UNAIRE] (CTE_ENTIERE | SYMBOLE [TUPLE] | TUPLE) [OP_BINAIRE EXPR]
static void SOUS_EXPR(AST &expr) {
	AST operande;
	AST *courant = &operande;

	if (opUnaire())
		// On attachera le reste à cet opérateur
		courant = &courant->attach(ES_OP_UNAIRE, lit());

	if (prochain(CTE_NOMBRE))
		courant->attach(ES_JETON, lit());
	else if (prochain(IDENTIFICATEUR)) {
		SYMBOLE(*courant);
		if (prochain(PAR_OUVRANTE))
			TUPLE(*courant);
	}
	else if (prochain(PAR_OUVRANTE)) {
		AST tuple;
		TUPLE(tuple);
		// Tuple à un seul élément = expression
		// FIXME: optimisation haut niveau de l'arbre?
		if (tuple.fils.size() == 1) {
			tuple.removeRoot();			// <TUPLE>
			tuple.removeRoot();			// <EXPRESSION>
		}
		courant->attach(tuple);
	}
	else
		erreur("expression attendue");

	// Opérateur binaire + autre expr
	if (opBinaire()) {
		AST operation(ES_OP_BINAIRE, lit()), operande2;
		SOUS_EXPR(operande2);
		operation.attach(operande);
		operation.attach(operande2);
		expr.attach(operation);
	}
	else
		expr.attach(operande);
}

static void EXPR(AST &arbre) {
	AST expr(ES_EXPRESSION);
	SOUS_EXPR(expr);
	arbre.attach(expr);
}

Ca me donne pour l'instant un arbre associatif à droite et sans priorité des opérateurs en notation préfixée, ce qui correspond à ma grammaire. Happy! smile Exemple pour a=0+(1*-2)-3;
<PROG>
    <BLOC_INSTRUCTION>
        <AFFECTATION>
            <SYMBOLE {IDENTIFICATEUR 'a'}>
            <EXPRESSION>
                <OP_BINAIRE {OP_PLUS '+'}>
                    <JETON {CTE_NOMBRE '0'}>
                    <OP_BINAIRE {OP_MOINS '-'}>
                        <OP_BINAIRE {OP_FOIS '*'}>
                            <JETON {CTE_NOMBRE '1'}>
                            <OP_UNAIRE {OP_MOINS '-'}>
                                <JETON {CTE_NOMBRE '2'}>
                        <JETON {CTE_NOMBRE '3'}>

Maintenant je vais virer ça et faire avec une conversion RPN smile
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

34

Bon j'ai terminé ma conversion RPN smile En fait ce n'est pas exactement du RPN, mais une notation hiérarchique. Par exemple 1 + 2 est noté (+(1, 2)), 1+2+3 est noté (+(+(1, 2), 3), et ainsi de suite. Cela me facilitera certainement la vérification des types et du nombre d'arguments, ainsi que la cohérence globale (par exemple si j'écris 1*, cela ne crée pas d'erreur, par contre il est clair que la multiplication a besoin de plus d'un argument).
Pour faire ça, j'ajoute les opérandes dans un arbre 'expr', et quand je dépile un opérateur ou une fonction, je crée un nouvel arbre avec cet opérateur pour racine, et j'y attache l'ancien arbre 'expr'. Le nouvel arbre devient alors l'arbre courant 'expr'. Pour générer le code j'imagine qu'un bête parcours en profondeur fera l'affaire.
(Je détaille ma démarche car ça peut toujours être utile à qqn dans le futur, ou éventuellement si vous voulez me corriger parce que je dis de la merde grin)

En parallèle je suis en train de songer à la création d'un petit processeur virtuel pour lequel je vais générer mon code. Ce qui semble le plus immédiat c'est bien sûr un processeur à pile, mais c'est pas très réaliste (et puis ça bypassera l'allocation des registres et tout). Donc je pense que je vais plutôt partir sur un processeur RISC 16-bits à architecture Harvard, afin de pouvoir avoir 64k de code et 16k de données + 16k paginés. Je complèterai avec 8k de RAM, 16k de VRAM (ben oui on va en faire une console), 4k de SRAM et 4k d'IO. Miam, ça va être l'occasion de mêler mon intérêt pour l'émulation avec celui de la compilation ^^
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

35

oui, fais un truc a registres, pas à pile, sinon c'est de la triche, c'est "trop facile" grin (disons moins difficile ^^)

36

Ok, c'est bien ce que je pensais merci smile
Je suis en train de coder l'assembleur, quel merde en fait d'avoir fait un processeur RISC, sans un tas de pseudo instructions tu fais pas grand chose... en plus les performances seront certainement toutpourries.
Pour l'instant une petite boucle en ASM:
	.section text
main:
	MOV r0, 0

boucle:                     ; r0 = 0 .. 10
	ADD r0, 1            ; r0 = r0 + 1
	SKIPEQ r0, 10, 1     ; if (r0 == 10) pc = pc + 1; (sortie de la boucle)
	GOTO boucle

Génère en fait le code suivant:
0000  MOV r0, 0
0002  MOV r12, 1
0004  ADD r0, r12
0006  MOV r12, 10
0008  SKIPEQ r0, r12, 1
000a  BRA -5    ; retour à MOV r12, 1

Avec r12 (tmp) étant un registre temporaire, car seul toute l'arithmétique se fait avec des registres, sauf mov.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

37

quel merde en fait d'avoir fait un processeur RISC, sans un tas de pseudo instructions tu fais pas grand chose

oui
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

38

J'ai avancé dans mon assembleur. C'est une grosse escroquerie ce truc, franchement si ça marche on peut me décerner la palme du bourrin happy
En fait le truc c'est que mon jeu d'instructions est tellement minimal qu'il n'est vraiment pas orthogonal. Prenons une instruction CPU bien pourrie: le branchement conditionnel (B[xx] ra, rb, saut_relatif_si_succès avec xx code de condition). Déjà il y a pour 14 bits d'opérande (sur 16), donc seulement 3 pour l'offset de branchement, c'est-à-dire [-4 .. +3].
Maintenant j'écris ceci:
:a
	BRA :b
	MOV r0, 0
	BNE r0, 0, :a
:b
	NOP

Le machin va me générer cela (il va mettre le 0 dans un registre, at, car BNE s'attend à ça seulement):
0000  BRA 3		; @0008
0002  MOV r0, 0
0004  MOV at, 0
0006  BNE r0, at, -4	; @0000
0008  NOP

Mais remplaçons bêtement le MOV r0, 0 par MOV r0, -1, qui ne peut plus être fait en une instruction:
0000  BRA 5		; @000c
0002  MOV r0, 255 (-1)
0004  EXT r0
0006  MOV at, 0
0008  BEQ r0, at, 1	; @000a
000a  BRA -6		; @0000
000c  NOP

(pendant l'exécution d'une instruction, pc vaut 'adresse de l'instruction exécutée' + 2. BRA -6 équivaut à SUB pc, 12)
Cette fois le le BNE est remplacé par un BEQ (inverse) qui skippe un branchement standard pour revenir plus haut. En fait tout le code a bougé, puisque l'instruction devenant plus grande car le label n'était pas assez proche, tout le reste du code est décalé, et et d'autres sauts peuvent éventuellement devenir à leur tour trop gros et nécessiter des instructions supplémentaires.
Bref -> grosse boucle while (des trucs ont bougé) { génère du code en fonction des labels actuels et ajuste la position des labels en fonction du nouveau code } comme un méga bourrin, et si un jour ça bloque on remplacera par un for grin
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

39

Bah pourquoi pas, ca peut être une heuristique.

Sinon il faut que tu résolves ça comme un problème combinatoire (où tu peux bouger les blocs pour minimiser la taille des sauts), avec un peu de chance tu auras moins d'itérations à faire.

Edit: par contre je suis pas sur d'avoir bien compris ton truc. Si tu as la possibilité d'éviter de générer du code en trop, ou toucher à du code généré, c'est évidemment ce qu'il faut faire.
Tout ce qui passe pas par le port 80, c'est de la triche.

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

41

./39> Je ne comprends pas ta question confus
En fait je ne connais pas à l'avance l'emplacement des labels, étant donné que ça dépend des instructions et pseudo instructions qui seront effectivement générées. Du coup je dois générer des instructions et tenter de les réduire par la suite. Mais je me doutais bien que ça ne fonctionnerait pas. Je prends un exemple extrêmement simple, mais on peut en trouver des plus complexes qui posent le même problème:
BRA :a    ; goto 'a' (adresse 0)
:a        ; label 'a' (adresse 2)

Au début il ne connaît pas encore l'emplacement de :a, donc il va générer l'instruction la plus large. Ensuite il va trouver :a = 2 et se rendre compte qu'il peut réduire l'instruction à zéro octets (en effet, elle génèrerait BRA 0, qui est inutile).
Ensuite en regénérant le code avec :a = 0 on va cette fois faire BRA :0 qui va générer une instruction (BRA -1), donc déplaçant :a à 2. Ensuite rebelotte. On peut "patcher" ce cas facilement en supprimant une instruction de 0 octet, mais j'imagine qu'il y a d'autre cas où ça va merder, mais je n'arrive pas à trouver de contre exemple sad Et je n'arrive pas non plus à prouver qu'une optimisation (saut/chargement sur moins d'instructions) génèrera un code plus petit dans tous les cas (i.e. il n'y a jamais de répercussions).
Des idées?
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

42

pour gérer les labels?

oué tu génères pas un texte mais une liste d'instructions (linkedlist en java, etc)

et les labels sont attachés aux index des instructions.

du coup une fois que tout est généré il suffit de retraverser la liste et de noter l'offset véritable qui se trouve associé à chaque label.

imagine tu mets un label après la 4e instruction, ok tu connais pas son offset.
on finit toute la génération comme ça.
ensuite on reprend la liste à partir de zéro.
on encode les instructions 1 à 4, TAC maintenant on connait l'offset de ce label, on le note.
Ensuite on re-reprend à zéro et on remplace toutes les références.
mais ça marche que si tu connais la taille de chaque emplacement de label.

43

Normalement, l'idée c'est d'essayer d'abord avec la longueur minimale, puis de "relaxer" en des longueurs plus longues là où c'est nécessaire. Si tu commences par la longueur la plus longue, puis optimises (comme le fait ld-tigcc d'ailleurs), tu peux te retrouver avec un cas comme:
lbl_1:
bra lbl_2
...
bra lbl1
lbl2:

que tu ne peux pas optimiser en optimisant un branchement à la fois parce que tu dois optimiser les 2 en même temps pour que ça rentre (le problème se produit quand ... a exactement la longueur maximale). Le désavantage de la méthode de relaxation, c'est que le code créé au départ n'est pas valide, ce n'est qu'à relaxation terminée qu'il est valide. Avec la méthode d'optimisation, le code est valide à toutes les étapes. Mais vu ton offset maximal très petit, le cas problème risque d'être assez fréquent et donc de te faire perdre pas mal de place si tu utilises la méthode d'optimisation.

Il me semble que GNU as utilise la méthode de relaxation pour les références internes au fichier.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

44

squalyl> Hé, si j'ai bien compris ce que tu dis, c'est à peu près ce que j'ai fait (enfin, en C++, donc un vector d'instructions polymorphiques dont certaines d'entre elles sont des labels, mais ce serait effectivement plus malin de les séparer hehe)
Mais ta méthode nécessite elle aussi de passer n fois la liste des instructions en revue n'est-ce pas?
Perso la première fois les labels pointent à zéro, donc le code généré sera peut être minimal, peut être pas, tout dépend. Ensuite ils seront ajustés et au deuxième passage on pourra générer un code "correct". Enfin, pas complètement, étant donné que certaines instructions utilisent peut-être des labels "en avant" qui n'ont pas encore été mis à jour. Donc il faudra un troisième passage pour vérifier que tout est cohérent. Si quelque chose change à ce passage, il faut refaire tout, étant donné que les références vers les labels "en avant" ne sont plus valides. En gros on le refait tant qu'il y a du changement, et ça implique qu'à chaque passe la taille du code devrait soit toujours diminuer, soit toujours augmenter, sinon on pourrait avoir des blocages, comme mon cas plus haut.
A part ça la méthode d'optimisation à Kevin me semble plus propre, même si j'ai de la peine à voir la différence à l'implémentation, étant donné qu'une optimisation va nécessiter de tout regénérer à chaque fois, et ensuite éventuellement permettre une nouvelle optimisation non?
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

45

Brunni (./45) :
Mais ta méthode nécessite elle aussi de passer n fois la liste des instructions en revue n'est-ce pas?


justement je suis pas sur, il m'a semblé que oui, puis que non, bref ça demande une étude approfondie (que je vais devoir bientot faire, en plus, mais je dois finir des trucs avant)

46

Je ne sais pas si ça peut encore aider, mais voici une grammaire LL(1) pour les expressions arithmétiques (forme BNF étendue)

Expr = Term { SumOp Term }
SumOp = "+" | "-"
Term = SignedFactor { ProdOp SignedFactor }
ProdOp = "*" | "/"
SignedFactor = [ NegateOp ] Factor
NegateOp = "-"
Factor = number | "(" Expr ")"

Sinon, notez que les "vrais" compilateurs n'utilisent en général pas les outils automatiques style yacc.

edit: j'avais oublié les parenthèses wink

47

oui enfin celui de javac il ressemble furieusement à ce qui a inspiré javacc quand même...

48

GCC utilisait Bison pour le C jusqu'à la version 4.0 et pour le C++ jusqu'à la version 3.3. Donc ça existe tout à fait, de vrais compilateurs utilisant un générateur de parseurs. Cela dit, depuis g++ 3.4 et depuis GCC 4.1, respectivement, le parseur est écrit à la main.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

49

c'est bien pour ça que je n'ai pas dit "aucun" ou "tous les"

pour gcc, je ne savais pas qu'ils avaient abandonné bison

edit:
deux petits liens parlant du pourquoi gcc est passé au parseur fait main
http://gcc.gnu.org/ml/gcc/2000-10/msg00573.html
http://gcc.gnu.org/ml/gcc/2000-10/msg00574.html

50

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.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

51

Kevin Kofler (./48) :
GCC utilisait Bison pour le C jusqu'à la version 4.0 et pour le C++ jusqu'à la version 3.3. Donc ça existe tout à fait, de vrais compilateurs utilisant un générateur de parseurs. Cela dit, depuis g++ 3.4 et depuis GCC 4.1, respectivement, le parseur est écrit à la main.



hum


godzil@Maya ~ $ find . | grep -e "\.y$"
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/gengtype-yacc.y
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/treelang/parse.y
./Code/gcc4ti-pool/g/gcc-4.1.2/intl/plural.y


Bizzare je me demande que font des fichier .y dans gcc 4.1.2 hum


Il y a meme du (f)lex sick
godzil@Maya ~ $ find . | grep -e "\.l$"
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/gengtype-lex.l
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/treelang/lex.l
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

52

ls -l **/*.y
feel the power of zsh
avatar
I'm on a boat motherfucker, don't you ever forget

53

Brunni (./50) :
./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 ^^

Tu t'y es mal pris alors, parce que les grammaires LALR(1) comme utilisées par Bison permettent parfaitement de décrire la priorité et l'associativité. C'est même plutôt simple.
Godzil (./51) :
Bizzare je me demande que font des fichier .y dans gcc 4.1.2 hum

./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/gengtype-yacc.y

Utilisé dans l'outil gengtype qui n'est utilisé que pendant la compilation de GCC lui-même (ça extrait les types pour le garbage collector intégré à GCC).
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/treelang/parse.y

La grammaire pour le langage jouet treelang, un frontend jouet qui ne sert pas à grand chose.
./Code/gcc4ti-pool/g/gcc-4.1.2/intl/plural.y

Ça fait partie de gettext.
Il y a meme du (f)lex sick
godzil@Maya ~ $ find . | grep -e "\.l$"
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/gengtype-lex.l
./Code/gcc4ti-pool/g/gcc-4.1.2/gcc/treelang/lex.l

Cf. les remarques sur gengtype et le langage treelang.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

54

SebRmv (./46) :
Sinon, notez que les "vrais" compilateurs n'utilisent en général pas les outils automatiques style yacc.


En effet, ETP-Basic Compiler n'en utilise pas.

dehors
Tout ce qui passe pas par le port 80, c'est de la triche.

55

Je ne crois pas me tromper en disant que ghc n'en utilise pas.
Idem pour scala (là, j'en suis sur vu que je connais l'équipe et leur avis sur les outils automatiques)

56

Tu as fait l'EPFL? smile
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

57

Eh oui, c'était le bon temps de la thèse grin

58

Brunni (./34) :
En parallèle je suis en train de songer à la création d'un petit processeur virtuel pour lequel je vais générer mon code. Ce qui semble le plus immédiat c'est bien sûr un processeur à pile, mais c'est pas très réaliste (et puis ça bypassera l'allocation des registres et tout). Donc je pense que je vais plutôt partir sur un processeur RISC 16-bits à architecture Harvard, afin de pouvoir avoir 64k de code et 16k de données + 16k paginés. Je complèterai avec 8k de RAM, 16k de VRAM (ben oui on va en faire une console), 4k de SRAM et 4k d'IO. Miam, ça va être l'occasion de mêler mon intérêt pour l'émulation avec celui de la compilation ^^

Tiens, ça me fait penser au processeur RISC 16 bits que j'ai fait créer à mes élèves en début d'année hehe (mais après, il a été implémenté en FPGA, c'est encore plus mieux tongue )
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

59

Ca c'est sûr, j'aimerais bien savoir le faire ^^
D'ailleurs il ressemble à quoi?
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

60

Le 68000 est concidéré comme un "processeur a pile" ^^ (meme si ça ne transparais pas vraiment sorry)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.