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 ?
D'abord le nombre de fautes d'orthographe, d'accord etc. mais on peut mettre ça sur le dos de la rédaction qui n'a pas corrigé ou même relu. C'est pourtant pas sorcier, c'est pas de la technique.
Ensuite, il y a plusieurs cafouillages comme confondre "word" et "world". Je n'ai pas l'article sous les yeux (je crois que c'était pour "VLIW") mais j'ai noté plusieurs trucs qui m'ont fait sursauter. Passons.
Faire sauter le "-" : je n'en ai rien à faire, tu es majeur et tu sais que seule l'orthographe "F-CPU" est déposée à l'INPI et à l'ICANN. C'est pour cette raison-là que j'essaie de me tenir à cela.
sachant que fcpu.com était déjà pris au moment d'acheter la marque et le DNS, on a dû choisir la version avec "-". Voilà pour la petite histoire : le "-" n'a aucune signification mais son en son absence on n'est pas à l'abris des emmerdes.
Je me souviens aussi des paragraphes sur le SRB : c'est pourtant marqué dans le manuel et ça veut dire "Smooth Register Backup", une technique destinée à réduire la latence des interruptions et de la sauvegarde du contexte précédent, grâce à une assistance HW pour
sauvegarder les registres au fur et à mesure de leur besoin. C'est ça qui a permis à l'époque de faire avaler la pilule des 64 registres, ce qui prendrait au moins 64*4=256 octets et 64 cycles pour sauvegarder en utilisant des instructions ! Avec un peu d'astuce et en ajoutant qqs circuits bien conçus, plus de problème.
On peut retrouver la justification même dans le vieux manuel pourri en ligne (voir http://www.f-cpu.de/man/i7/part4.html#SRB(...) ).
Il y a encore d'autres trucs mais c'est plutôt le genre de détail qui n'a pas d'importance pour ceux qui découvrent, je n'ai pas non plus envie de te descendre en flèche ou de passer pour un vieu crouton :-)
La vraie conclusion c'est que toutes ces erreurs auraient pu être évitées par une relecture croisée. Personne n'est parfait mais les solutions sont bien connues. J'espère aussi que les prochains articles seront plus posés, plus clairs et plus structurés afin de ne pas noyer les pauvres linuxiens sous une montagne de termes trop "l33t3" :-) déjà que j'y comprends rien à LDAP, IPsec, j'utilise ni CVS ni GPG...
publicité gratuite : j'ai écrit un article qui paraitra probablement dans le prochain numéro de LM. J'espère que ce sera suffisamment accessible et que des personnes oseront installer et lancer les outils décrits.
J'ai aussi dans mon "pipeline" un article encore plus dingue que le premier article de nicO dans LMF. Ca présente les méthodes de codage pour programmer en RISC et évidemment en utilisant les règles de codage du FC0. En plus c'est super-utile car le code est une DCT de Winograd, le truc qui permet de faire l'analyse spectrale de 8 échantillons avec seulement 5 multiplications :-)
Allez, dernière URL : les sources les plus frais sont à http://f-cpu.seul.org/new(...) : bon surf :-) La dernière archive qui j'y ai uploadé (http://f-cpu.seul.org/new/stable_yg_12_31_2001.tgz(...)) est considérée comme "stable" mais on continue à travailler dessus. Ca permet au moins d'utiliser les outils décrits dans l'article prochain, car toute la procédure de compilation a été remise à plat.
YG (qu'a pas un seul XP mais j'men fous, j'ai jamais vu nicO mouler sur la tribune :-P)
[^] # Re: article plus général
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 4.
[^] # 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
[^] # dégonflage de chevilles
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Article sur le FCPU de LMF. Évalué à 10.
Il y a plusieurs points que je voudrais soulever.
D'abord le nombre de fautes d'orthographe, d'accord etc. mais on peut mettre ça sur le dos de la rédaction qui n'a pas corrigé ou même relu. C'est pourtant pas sorcier, c'est pas de la technique.
Ensuite, il y a plusieurs cafouillages comme confondre "word" et "world". Je n'ai pas l'article sous les yeux (je crois que c'était pour "VLIW") mais j'ai noté plusieurs trucs qui m'ont fait sursauter. Passons.
Faire sauter le "-" : je n'en ai rien à faire, tu es majeur et tu sais que seule l'orthographe "F-CPU" est déposée à l'INPI et à l'ICANN. C'est pour cette raison-là que j'essaie de me tenir à cela.
sachant que fcpu.com était déjà pris au moment d'acheter la marque et le DNS, on a dû choisir la version avec "-". Voilà pour la petite histoire : le "-" n'a aucune signification mais son en son absence on n'est pas à l'abris des emmerdes.
Je me souviens aussi des paragraphes sur le SRB : c'est pourtant marqué dans le manuel et ça veut dire "Smooth Register Backup", une technique destinée à réduire la latence des interruptions et de la sauvegarde du contexte précédent, grâce à une assistance HW pour
sauvegarder les registres au fur et à mesure de leur besoin. C'est ça qui a permis à l'époque de faire avaler la pilule des 64 registres, ce qui prendrait au moins 64*4=256 octets et 64 cycles pour sauvegarder en utilisant des instructions ! Avec un peu d'astuce et en ajoutant qqs circuits bien conçus, plus de problème.
On peut retrouver la justification même dans le vieux manuel pourri en ligne (voir http://www.f-cpu.de/man/i7/part4.html#SRB(...) ).
Il y a encore d'autres trucs mais c'est plutôt le genre de détail qui n'a pas d'importance pour ceux qui découvrent, je n'ai pas non plus envie de te descendre en flèche ou de passer pour un vieu crouton :-)
La vraie conclusion c'est que toutes ces erreurs auraient pu être évitées par une relecture croisée. Personne n'est parfait mais les solutions sont bien connues. J'espère aussi que les prochains articles seront plus posés, plus clairs et plus structurés afin de ne pas noyer les pauvres linuxiens sous une montagne de termes trop "l33t3" :-) déjà que j'y comprends rien à LDAP, IPsec, j'utilise ni CVS ni GPG...
publicité gratuite : j'ai écrit un article qui paraitra probablement dans le prochain numéro de LM. J'espère que ce sera suffisamment accessible et que des personnes oseront installer et lancer les outils décrits.
J'ai aussi dans mon "pipeline" un article encore plus dingue que le premier article de nicO dans LMF. Ca présente les méthodes de codage pour programmer en RISC et évidemment en utilisant les règles de codage du FC0. En plus c'est super-utile car le code est une DCT de Winograd, le truc qui permet de faire l'analyse spectrale de 8 échantillons avec seulement 5 multiplications :-)
Allez, dernière URL : les sources les plus frais sont à http://f-cpu.seul.org/new(...) : bon surf :-) La dernière archive qui j'y ai uploadé (http://f-cpu.seul.org/new/stable_yg_12_31_2001.tgz(...)) est considérée comme "stable" mais on continue à travailler dessus. Ca permet au moins d'utiliser les outils décrits dans l'article prochain, car toute la procédure de compilation a été remise à plat.
YG (qu'a pas un seul XP mais j'men fous, j'ai jamais vu nicO mouler sur la tribune :-P)