quels que soient mes reproches envers nicO (ça se règle souvent autour d'une table avec un crayon et beaucoup de papier :-D), ses efforts auront été cela : une continuation du projet, pour permettre de le faire mieux connaitre. Pour le reste, nicO est majeur et responsable.
Personnellement, j'ai souvent plusieurs discours selon la personne à laquelle je m'adresse : soit un non-initié qui n'a jamais vu le comp de comp.arch, je lui tends alors la "brochure" qui présente rapidement le projet sans l'effrayer.
Il y en a une qui traine à http://www.f-cpu.de/brochure/(...) si cela vous dit.
Puis il y a ceux qui sont avides de sensations fortes et là, c'est le manuel qu'il faut leur tendre. Une vieille version
est disponible en ligne à http://www.f-cpu.de/man/i7/summary.html(...) (depuis, on a commencé à écrire du code et le délégué au manuel n'a pas fait tout son boulot, veuillez l'excuser).
Enfin il y a les spécialistes du VHDL et là c'est http://www.f-cpu.seul.org/new/stable_yg_12_31_2001.tgz(...)
Il y a plein de choses dont un HOWTO sur l'utilisation des outils de VHDL. La version française "non-geek" paraitra dans LM bientöt.
Peut-être nicO a-t-il voulu en faire trop à la fois ?
Il y a des fois où je me sens pas, quand j'écris du code ou des articles.
Au moins, à défaut de demander les réactions avant publication, il demande après :-)
Quant à programmer en ASM, j'en ai fait assez sur x86 pour te dire ... que F-CPU est plus facile :-) Il est certain que des techniques avancées et récentes de programmations sont nécessaires et peu développées, mais ce n'est rien comparé au casse-burnes d'Intel.
Code à l'appui.
Quant aux compilos, ils crachent ce qu'on leur donne : je ne les utilise que parce que je développe un algo ou parcequ'il faut qu'il soit portable sur d'autres archis.
Pour ce qui est de l'expertise, oui on a besoin de gens qui ont tâté du Synopsys ou de l'ATPG, mais aussi de personnes "normales" (hmm, oui, ça existe). A trop faire de la technique, le projet d'assoce 1901 n'avance pas, et les sites webs sont devenus complétement chaotiques...
Si vous voyez ce que je veux dire.
Au fait pour la prédiction de branchement l'état actuel c'est : y'en a pas pour FC0. En fait il y a 1 cycle de pénalité par branchement pris, mais c'est trop peu pour justifier du HW supplémentaire. En plus le pipeline du FC0 est "OOOC" et ne supporterait pas une exécution spéculative, donc la prédiction ne sert à rien pour l'instant. Mais on a réservé des espaces pour les implémentations plus compliquées que FC0, au cas où.
Toutefois la prédiction de branchement est un mécanisme qui peut devenir critique pour un programme : il n'y a qu'à lire les chapitres de recommandations des fabricants comme Intel (X86, ia64 et autres), Motorola/IBM (POWER, PowerPC), Digital/Compaq (Alpha) etc pour voir que le style de programmation influence lourdement l'efficacité du code, et cela même à un haut niveau d'abstraction. Je pense que trop de monde se moque de ces "détails" qui font que le code "a l'air moins beau" mais terriblement plus efficace. Ce sont ces mêmes personnes qui sont ensuite embauchées dans les boites pour cracher du source toute la journée, des usines à gaz qui nécessitent des machines toujours plus grosses pour faire encore moins... En cela, je pense que les articles de nicO sont importants. Peut-être cela incitera les gens à lire "le Zen de l'optimisation" de Michael Abrash, par exemple ?
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 10.
quels que soient mes reproches envers nicO (ça se règle souvent autour d'une table avec un crayon et beaucoup de papier :-D), ses efforts auront été cela : une continuation du projet, pour permettre de le faire mieux connaitre. Pour le reste, nicO est majeur et responsable.
Personnellement, j'ai souvent plusieurs discours selon la personne à laquelle je m'adresse : soit un non-initié qui n'a jamais vu le comp de comp.arch, je lui tends alors la "brochure" qui présente rapidement le projet sans l'effrayer.
Il y en a une qui traine à http://www.f-cpu.de/brochure/(...) si cela vous dit.
Puis il y a ceux qui sont avides de sensations fortes et là, c'est le manuel qu'il faut leur tendre. Une vieille version
est disponible en ligne à http://www.f-cpu.de/man/i7/summary.html(...) (depuis, on a commencé à écrire du code et le délégué au manuel n'a pas fait tout son boulot, veuillez l'excuser).
Enfin il y a les spécialistes du VHDL et là c'est http://www.f-cpu.seul.org/new/stable_yg_12_31_2001.tgz(...)
Il y a plein de choses dont un HOWTO sur l'utilisation des outils de VHDL. La version française "non-geek" paraitra dans LM bientöt.
Il y a encore d'autres sites externes, plus ou moins mal foutus (et surtout peu à jour) à voir sur http://www.f-cpu.org/(...)
comme celui de Philippe Trbich http://philippe.trbich.free.fr/(...)
qui a traduit une partie du manuel http://philippe.trbich.free.fr/pub/fcpu/manuel/(...) mais je m'égare.
Peut-être nicO a-t-il voulu en faire trop à la fois ?
Il y a des fois où je me sens pas, quand j'écris du code ou des articles.
Au moins, à défaut de demander les réactions avant publication, il demande après :-)
Quant à programmer en ASM, j'en ai fait assez sur x86 pour te dire ... que F-CPU est plus facile :-) Il est certain que des techniques avancées et récentes de programmations sont nécessaires et peu développées, mais ce n'est rien comparé au casse-burnes d'Intel.
Code à l'appui.
Quant aux compilos, ils crachent ce qu'on leur donne : je ne les utilise que parce que je développe un algo ou parcequ'il faut qu'il soit portable sur d'autres archis.
Pour ce qui est de l'expertise, oui on a besoin de gens qui ont tâté du Synopsys ou de l'ATPG, mais aussi de personnes "normales" (hmm, oui, ça existe). A trop faire de la technique, le projet d'assoce 1901 n'avance pas, et les sites webs sont devenus complétement chaotiques...
Si vous voyez ce que je veux dire.
Au fait pour la prédiction de branchement l'état actuel c'est : y'en a pas pour FC0. En fait il y a 1 cycle de pénalité par branchement pris, mais c'est trop peu pour justifier du HW supplémentaire. En plus le pipeline du FC0 est "OOOC" et ne supporterait pas une exécution spéculative, donc la prédiction ne sert à rien pour l'instant. Mais on a réservé des espaces pour les implémentations plus compliquées que FC0, au cas où.
Toutefois la prédiction de branchement est un mécanisme qui peut devenir critique pour un programme : il n'y a qu'à lire les chapitres de recommandations des fabricants comme Intel (X86, ia64 et autres), Motorola/IBM (POWER, PowerPC), Digital/Compaq (Alpha) etc pour voir que le style de programmation influence lourdement l'efficacité du code, et cela même à un haut niveau d'abstraction. Je pense que trop de monde se moque de ces "détails" qui font que le code "a l'air moins beau" mais terriblement plus efficace. Ce sont ces mêmes personnes qui sont ensuite embauchées dans les boites pour cracher du source toute la journée, des usines à gaz qui nécessitent des machines toujours plus grosses pour faire encore moins... En cela, je pense que les articles de nicO sont importants. Peut-être cela incitera les gens à lire "le Zen de l'optimisation" de Michael Abrash, par exemple ?
YG