A l'extreme, selon ta définition, une ALU c'est un CPU.
Non, car il n'y a pas de gestion des instructions, par exemple.
qui sait juste calculer "f(x) = 4*x" et "g(x) = 5*x" avec un jeu d'instructions qui comporte deux instructions "f" "g".
Si tu compiles un code C, ayant
int f(int x) {return 4*x;}; int g(int x){ return 5*x;}
Cela aurait un sens que cela soit le résultat après simplification. Cela ne serait plus un cpu, c'est vrai. Sauf que ce n'est pas un code C qui fait quelques choses, typiquement, il n'y a aucune IO.
Je dis qu'on peut faire un circuit spécifique qui fait du décodage MPEG4 qui n'est pas un CPU.
On peut toujours tout faire en hard, c'est moi qui avait pris un exemple. En plus, le tien est un décodeur, qui est infiniment plus simple qu'un codeur.
C'est une évidence.
Non justement. Si tu pars sur un array de cpu vliw comme pattern de base, et tu compiles des blocs pour miner du bitcoin, ton code peut devenir une centaine de core avec des instructions sha cablé, qui seront bien plus rapide qu'un x86.
Les performances des CPUs implémentés dans les FPGA sont très très faibles.
Oui si tu pars de cpu monocore simple, mais commence avec du multicore multithreadé en vliw, ce n'est pas automatique du tout.
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.
Je ne pense pas que l'on a déjà fait. C'était ma proposition à la question du forum :)
On peut imaginer faire une machine virtuelle pour GCC, et générer le ou les cpu a partir d'un template de cpu et de ce code objet. C'est l'idée.
[^] # Re: Probablement une mauvaise idée...
Posté par Nicolas Boulay (site web personnel) . En réponse au message Utiliser un FPGA pour accélérer les compilations ?. Évalué à 4.
Non, car il n'y a pas de gestion des instructions, par exemple.
Si tu compiles un code C, ayant
int f(int x) {return 4*x;}; int g(int x){ return 5*x;}
Cela aurait un sens que cela soit le résultat après simplification. Cela ne serait plus un cpu, c'est vrai. Sauf que ce n'est pas un code C qui fait quelques choses, typiquement, il n'y a aucune IO.
On peut toujours tout faire en hard, c'est moi qui avait pris un exemple. En plus, le tien est un décodeur, qui est infiniment plus simple qu'un codeur.
Non justement. Si tu pars sur un array de cpu vliw comme pattern de base, et tu compiles des blocs pour miner du bitcoin, ton code peut devenir une centaine de core avec des instructions sha cablé, qui seront bien plus rapide qu'un x86.
Oui si tu pars de cpu monocore simple, mais commence avec du multicore multithreadé en vliw, ce n'est pas automatique du tout.
Je ne pense pas que l'on a déjà fait. C'était ma proposition à la question du forum :)
On peut imaginer faire une machine virtuelle pour GCC, et générer le ou les cpu a partir d'un template de cpu et de ce code objet. C'est l'idée.
"La première sécurité est la liberté"