Oui mais personne n'utilise une FSM toute seul, c'est pour ça que j'ai préciser + opérateur et comparateur.
Je suis pas sur que ça suffise pour faire un truc Turing complet. Doit manquer une instruction pour faire des sauts. Cela dit, ça n'enlève rien à la distinction automate d'état fini/machine de Turing.
Tu mélanges la définition d'un cpu (== vue de l'extérieur) et son architecture.
Ok la dessus.
Un cpu, c'est une boite noire dans lequel plusieurs bus rentre et sorte, et qui est capable d’exécuter des instruction. On peut imaginer que ces instructions soient dans une ROM.
C'est vraiment une définition ultra large de CPU. Donc, ça explique une partie de l'incompréhension on avait pas la même. Donc je peux faire un "CPU" qui sait juste calculer "f(x) = 4*x" et "g(x) = 5*x" avec un jeu d'instructions qui comporte deux instructions "f" "g". A l'extreme, selon ta définition, une ALU c'est un CPU.
Non!! Tu racontes n'importe quoi. L'encodeur MP4 embarqué dans l'omap4 de TI, c'est 2 ARM M0 ou 4, qui pilote 2 DSP.
Tu mélanges tout sur ce coup. J'ai pas dit qu'on pouvait pas faire un encodeur MPEG4 avec un DSP ou un CPU.
Je dis qu'on peut faire un circuit spécifique qui fait du décodage MPEG4 qui n'est pas un CPU.
Oui, c'est compliqué et surement lent, mais cela ne veut pas dire que ça l'est à coup sûr.
C'est une évidence. Si on fait un CPU avec une architecture moins bonne et une fréquence divisée par 10... Les performances des CPUs implémentés dans les FPGA sont très très faibles. C'est d'ailleurs pour ça que des fabriquants mettent des cœurs ARM et un FPGA sur la même puce.
J'ai du oublier de dire, que c'est absolument n'importe quoi de croire que faire des va et vient avec le x86 pouvait avoir un intérêt
Oui, oui... Il faut tout faire sur le FPGA (on se comprend vraiment pas). Juste que le CPU implémenté sur le FPGA peut avoir des instructions qui font plus ou moins de choses. Soit on a que des instructions génériques (les cmp, add, sub, jmp, jne classiques des jeux d'instructions) (mon cas (i). Soit on fait un CPU a une seule instructions (compile) qui fait tout (mon cas (ii)). Entre les deux, on peut comme tu dis "détecter les ensembles d'instructions" utiles, les fusionner pour en faire une instruction unique qu'on ajoute à l'instruction set de notre CPU. C'est évidemment l'approche raisonnable.
Le considère gcc uniquement comme un code C. Donc, le génerateur de bitstream peut déduire facilement les ensembles d'instructions les plus utiles et les fusionner ou dupliqué pour créer un CPU de fpga ultra rapide pour gcc.
Tu peux détailler ça ? Comment je passe de (Code source de gcc) -> (bitstream) ?
Est-ce que c'est :
1. J'ai un design de CPU générique flashable dans un FPGA. Je compile gcc pour ce CPU générique. J'obtiens le code assembleur de gcc.
2. Je détecte les ensembles d'instructions redondants dans l'assembleur générique généré par gcc. (Si ça existe, on utilise quoi comme genre de logiciels ?). On les instructions dans chacun des ensembles d'instructions pour créer des macro-instructions.
3. On ajoute ces macro-instructions au design de CPU générique qui devient un CPU "optimisé".
4. On modifie le code assembleur de gcc pour qu'il utilise les macro-instructions.
5. On flashe le CPU optimisé sur le FPGA. Et on exécute la version (4) de gcc sur le CPU optimisé.
Si on sait faire ça, c'est super impressionant ! Je serais intéressé si tu as des noms de logiciels / des tutoriels ou des papiers.
[^] # Re: Probablement une mauvaise idée...
Posté par X345 . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 2.
Je suis pas sur que ça suffise pour faire un truc Turing complet. Doit manquer une instruction pour faire des sauts. Cela dit, ça n'enlève rien à la distinction automate d'état fini/machine de Turing.
C'est vraiment une définition ultra large de CPU. Donc, ça explique une partie de l'incompréhension on avait pas la même. Donc je peux faire un "CPU" qui sait juste calculer "f(x) = 4*x" et "g(x) = 5*x" avec un jeu d'instructions qui comporte deux instructions "f" "g". A l'extreme, selon ta définition, une ALU c'est un CPU.
Tu mélanges tout sur ce coup. J'ai pas dit qu'on pouvait pas faire un encodeur MPEG4 avec un DSP ou un CPU.
Je dis qu'on peut faire un circuit spécifique qui fait du décodage MPEG4 qui n'est pas un CPU.
Très précisément, ça http://opencores.org/project,nova c'est pas un CPU. C'est un circuit dédié au décodage MPEG4.
C'est une évidence. Si on fait un CPU avec une architecture moins bonne et une fréquence divisée par 10... Les performances des CPUs implémentés dans les FPGA sont très très faibles. C'est d'ailleurs pour ça que des fabriquants mettent des cœurs ARM et un FPGA sur la même puce.
Oui, oui... Il faut tout faire sur le FPGA (on se comprend vraiment pas). Juste que le CPU implémenté sur le FPGA peut avoir des instructions qui font plus ou moins de choses. Soit on a que des instructions génériques (les cmp, add, sub, jmp, jne classiques des jeux d'instructions) (mon cas (i). Soit on fait un CPU a une seule instructions (compile) qui fait tout (mon cas (ii)). Entre les deux, on peut comme tu dis "détecter les ensembles d'instructions" utiles, les fusionner pour en faire une instruction unique qu'on ajoute à l'instruction set de notre CPU. C'est évidemment l'approche raisonnable.
Tu peux détailler ça ? Comment je passe de (Code source de gcc) -> (bitstream) ?
Est-ce que c'est :
1. J'ai un design de CPU générique flashable dans un FPGA. Je compile gcc pour ce CPU générique. J'obtiens le code assembleur de gcc.
2. Je détecte les ensembles d'instructions redondants dans l'assembleur générique généré par gcc. (Si ça existe, on utilise quoi comme genre de logiciels ?). On les instructions dans chacun des ensembles d'instructions pour créer des macro-instructions.
3. On ajoute ces macro-instructions au design de CPU générique qui devient un CPU "optimisé".
4. On modifie le code assembleur de gcc pour qu'il utilise les macro-instructions.
5. On flashe le CPU optimisé sur le FPGA. Et on exécute la version (4) de gcc sur le CPU optimisé.
Si on sait faire ça, c'est super impressionant ! Je serais intéressé si tu as des noms de logiciels / des tutoriels ou des papiers.