Il y avait 7 registres données et 7 registres adresses, mais ces derniers, plus nombreux, étaient plus efficaces car le numéro de registre indiquait si c'était pour lire ou écrire. L'architecture mémoire du YASEP est différente donc j'ai dû simplifier. Tant que la latence mémoire reste faible, ça va encore, mais si on doit accéder à de la DRAM, il faudra coder plus astucieusement (mais ça a été fait pour ça au début, l'utilisation de SRAM interne rapide n'était même pas envisagée au début).
Ca me fait penser au PIC16F84 qui a un système similaire, il a un registre d'adresse et de données indirect.
Oui mais le PIC16F n'a qu'un seul registre indirect. C'est absolument horrible. Les architectures suivantes en ont ajouté d'autres, parce qu'une pile câblée c'est gentil mais comment on fait du multiprocessing ? (réponse : on rame grave)
Point de vue compacité de code c'est pour moi similaire à une architecture load/store. Il faut relativement souvent fournir l'adresse également.
tout à fait.
Tu n'es pas trop à l'étroit ? parce que 5 registres (10 si tu fais du parking) ça me parait un peu court.
C'est évidemment très short, mais au début c'était pas mieux. J'étais parti sur 8 registres et 4 paires A/D mais je me suis rendu compte que l'accès à la mémoire était plus important, donc j'ai gratté sur 2 registres normaux. Je continue de réfléchir à une architecture à 32 registres adressables pour lever cette limite :-)
Ensuite, le YASEP n'est pas fait pour du gros calcul mais pour du contrôle, donc si vous avez déjà utilisé un PIC16F vous avez déjà l'esprit suffisamment flexible (ou mal tourné) pour vous en sortir. Et puis il faudra faire un bon compilo.
Mais c'est vrai que tu as la mémoire a coté pour bosser. Quelle est la latence d'accès à la mémoire vs les registres ?
sur les FPGA ProASIC3, avec le microYASEP (qui tourne à 20 MIPS) l'accès à un blockRAM interne est quasi immédiat.
Ensuite, rendre visible la mémoire au travers des registre, cela a deux avantages lorsque le système mémoire devient compliqué :
Cela permet de séparer les différents espaces mémoire. Avec 5 registres, on peut configurer la puce pour avoir 5 blocks différents, avec des propriétés et des attributions spécifiques. C'est super pratique, pas de contrôleur de bus qui va devoir multiplexer les bus, ou adapter les longueurs et les latences...
Cela permet aussi, grâce au parallélisme, de masquer par logiciel les latences de certains espaces mémoire. Un peu comme quand on codait le CDC6600. C'est de l'entrelacement logiciel. Il suffit de connaitre une adresse suffisamment à l'avance pour l'envoyer sur le registre d'adresse, on intercale ensuite un peu de boulot d'autre chose, et quand c'est fini, la donnée est disponible en lecture dans le registre de donnée. Donc même s'il y a plusieurs cycles de latence pour lire une DRAM externe, le cœur n'est pas bloqué, sans utiliser de mémoire cache ni de "Out Of Order".
J'ai pas cherché/trouvé le code VHDL pour voir comment tu avais architecturé ton pipeline par contre. Tu as une URL ?
Le cœur est dans http://yasep.org/VHDL/microYASEP.vhd , c'est moins de 400 lignes qui reprennent bloc par bloc l'image ci-dessus. J'ai conçu ce biniou en 1 semaine, il a fallu un à deux mois pour le mettre au point, et je n'avais pas encore les outils que j'ai à présent. J'avais au moins pu faire une démo des outils fin 2012, avec un morceau de code écrit dans l'interface JS, simulé dedans, puis exporté dans le simulateur VHDL qui affichait exactement la même chose sur un autre écran.
La structure interne est expliquée en détail dans http://archives.yasep.org/JMLL2012/slides/ que je conseille de lire avant d'essayer de déchiffrer le VHDL. Il y a aussi la conf en vidéo et audio (2h) à http://archives.yasep.org/JMLL2012/ (le serveur cafouille un peu, F5 F5 F5 en attendant que je migre autre part)
Encore une fois, c'est grâce à la simplicité du YASEP que j'ai pu avancer seul si loin. La complexité du YASEP est équivalente à peut-être 1/10 de FC0... Mais FC0 ne pourrait pas avancer sans tous les outils que j'ai mis au point pour le YASEP, souvent en pensant à m'en servir pour F-CPU. Il était donc temps de commencer à unifier tout ce bousin :-P
[^] # Re: RiscV et LowRisc
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 6.
bonsoir,
Seymour Cray faisait comme ça dans les années 60 : http://ygdes.com/CDC/cdc6600.html
Il y avait 7 registres données et 7 registres adresses, mais ces derniers, plus nombreux, étaient plus efficaces car le numéro de registre indiquait si c'était pour lire ou écrire. L'architecture mémoire du YASEP est différente donc j'ai dû simplifier. Tant que la latence mémoire reste faible, ça va encore, mais si on doit accéder à de la DRAM, il faudra coder plus astucieusement (mais ça a été fait pour ça au début, l'utilisation de SRAM interne rapide n'était même pas envisagée au début).
Oui mais le PIC16F n'a qu'un seul registre indirect. C'est absolument horrible. Les architectures suivantes en ont ajouté d'autres, parce qu'une pile câblée c'est gentil mais comment on fait du multiprocessing ? (réponse : on rame grave)
tout à fait.
C'est évidemment très short, mais au début c'était pas mieux. J'étais parti sur 8 registres et 4 paires A/D mais je me suis rendu compte que l'accès à la mémoire était plus important, donc j'ai gratté sur 2 registres normaux. Je continue de réfléchir à une architecture à 32 registres adressables pour lever cette limite :-)
Ensuite, le YASEP n'est pas fait pour du gros calcul mais pour du contrôle, donc si vous avez déjà utilisé un PIC16F vous avez déjà l'esprit suffisamment flexible (ou mal tourné) pour vous en sortir. Et puis il faudra faire un bon compilo.
sur les FPGA ProASIC3, avec le microYASEP (qui tourne à 20 MIPS) l'accès à un blockRAM interne est quasi immédiat.
Ensuite, rendre visible la mémoire au travers des registre, cela a deux avantages lorsque le système mémoire devient compliqué :
Cela permet de séparer les différents espaces mémoire. Avec 5 registres, on peut configurer la puce pour avoir 5 blocks différents, avec des propriétés et des attributions spécifiques. C'est super pratique, pas de contrôleur de bus qui va devoir multiplexer les bus, ou adapter les longueurs et les latences...
Cela permet aussi, grâce au parallélisme, de masquer par logiciel les latences de certains espaces mémoire. Un peu comme quand on codait le CDC6600. C'est de l'entrelacement logiciel. Il suffit de connaitre une adresse suffisamment à l'avance pour l'envoyer sur le registre d'adresse, on intercale ensuite un peu de boulot d'autre chose, et quand c'est fini, la donnée est disponible en lecture dans le registre de donnée. Donc même s'il y a plusieurs cycles de latence pour lire une DRAM externe, le cœur n'est pas bloqué, sans utiliser de mémoire cache ni de "Out Of Order".
oui, http://yasep.org/VHDL/
L'architecture du microYASEP est aussi expliquée par cette image http://archives.yasep.org/JMLL2012/slides/microYASEP1.png et détaillé par celle-ci
Plan détaillé
Le cœur est dans http://yasep.org/VHDL/microYASEP.vhd , c'est moins de 400 lignes qui reprennent bloc par bloc l'image ci-dessus. J'ai conçu ce biniou en 1 semaine, il a fallu un à deux mois pour le mettre au point, et je n'avais pas encore les outils que j'ai à présent. J'avais au moins pu faire une démo des outils fin 2012, avec un morceau de code écrit dans l'interface JS, simulé dedans, puis exporté dans le simulateur VHDL qui affichait exactement la même chose sur un autre écran.
La structure interne est expliquée en détail dans http://archives.yasep.org/JMLL2012/slides/ que je conseille de lire avant d'essayer de déchiffrer le VHDL. Il y a aussi la conf en vidéo et audio (2h) à http://archives.yasep.org/JMLL2012/ (le serveur cafouille un peu, F5 F5 F5 en attendant que je migre autre part)
Encore une fois, c'est grâce à la simplicité du YASEP que j'ai pu avancer seul si loin. La complexité du YASEP est équivalente à peut-être 1/10 de FC0... Mais FC0 ne pourrait pas avancer sans tous les outils que j'ai mis au point pour le YASEP, souvent en pensant à m'en servir pour F-CPU. Il était donc temps de commencer à unifier tout ce bousin :-P