J'aimerais avoir un feed-back pour voir les points qui coincent. Si ceux qui ont lu l'article pouvait laisser un commentaire, cela m'aiderait beaucoup.
Note du modérateur: Ceci n'est pas vraiment une nouvelle mais vu la qualité des articles de Nicolas dans LMF... nous encourageons les lecteurs à lui répondre.
Aller plus loin
- Linux Mag (12 clics)
- Site du F-CPU (14 clics)
# une petite reponse qui vaut ce qu'elle vaut...
Posté par blackshack . Évalué à 10.
esperons qu'il continu
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par SoWhat . Évalué à 10.
J'ai bien aimé les points sur le choix de la license et tout ce qui s'en suit.
Les points réellement techniques d'un tel article ne peuvent de toute façon pas s'adresser à de vrais débutants. J'ai trouvé cet article très interressant ( ok, je ne ferait plus de récursif avec des proc sparc, promis ;). bravo.
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Troy McClure (site web personnel) . Évalué à 10.
--
poulpe !
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Troy McClure (site web personnel) . Évalué à -1.
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Jean-Noël Avila . Évalué à 10.
Ces articles ne contiennent pas de finesses particulières vu qu'ils présentent des panoramiques de la technologie. Bien qu'ils soient tout à fait compréhensibles si on possède des bases en architecture informatique, il est regrettable qu'il attaque de manière trop abrupte certains points (ex : gestion de cache dans un processeur).
Le fait qu'il soit généraliste aurait du guider vers une approche plus douce, en évitant les non-dits. Je suis certain que celà aurait évité cette impression de "finesses cachées".
Par contre, les parallèles entre architectures internes et architectures distribuées sont saisissants. Ce sont des analogies comme celle-ci qui fournissent de bons repères pour la compréhension.
Enfin, je crois qu'il aurait fallu plus d'exemples chiffrés pour éclairer les principes (d'autant plus que des exemples d'architectures sont cités).
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par William Steve Applegate (site web personnel) . Évalué à 10.
Envoyé depuis mon PDP 11/70
[^] # Re: une petite reponse qui le vaut bien ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Article pour pro : donc plus il est pointu, plus il est interrescant.
Article pour neuneu : je ratisse large mais cela ne servirai pas à grand chose.
Mouais.
Je pense pas que le Finnois serait pas super heureux si seulement 1% des lecteurs seraient capable de comprendre les articles.
Le but de genre d'article sont multiples :
- Faire découvrire (aimer?) le hard
- Faire connaissance avec les CPU
- Faire du prior art (pour lutter contre d'hypothètique brevet)
- Attirer des bons
- Faire comprendre que le projet est sérieux
- Faire exploser nos ego...
Concernant les "moins" bon, il y a du gros travails de mise en forme et gestion de site web. De plus, les petits jeunes qui s'y mettent sérieusement peuvent aider après 1 an ou 2, à avoir lu et appris sur le sujet (compilation, microarchitecture, algorythme pour les unité de calculs, codage VHDL...).
"La première sécurité est la liberté"
[^] # Lefinnois, pas le Finnois, inculte ;)
Posté par Denis Bodor (site web personnel) . Évalué à 5.
Attend, je decortique....
[decortiking....]
0%...25%....50%...75%...100%
[decortiking done !]
C'est vrai, je pense que je ne serait pas super comptant si seulement 1% des lecteurs comprennent ce qu'ils lisent, autant pour eux, que pour moi que pour la boite :)
[^] # Re: une petite reponse qui vaut ce qu'elle vaut...
Posté par Yann Guidon (site web personnel) . É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
# RAV
Posté par Infernal Quack (site web personnel) . Évalué à -10.
Mais bon MA n'est pas parole d'évangile et puis je préfère MA~ ;)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# article plus général
Posté par gui_ . Évalué à 10.
En tout cas, merci pour les articles de LMF qui sont toujours interessant, même si l'on est pas un expert.
[^] # Re: article plus général
Posté par furai (site web personnel) . Évalué à 1.
[^] # Re: article plus général
Posté par gui_ . Évalué à 5.
En gros, un article d'initiation et de vulgarisation pour un neuneu complet.
[^] # Re: article plus général
Posté par Marc (site web personnel) . Évalué à 0.
f-cpu est u nbon sujet vu que ca parle de libre etc etc. Un article sur le fonctionement d'un processeur sortirait pas du cadre?
[^] # Re: article plus général
Posté par Sylvain Rampacek (site web personnel) . Évalué à 6.
Donc pour faire un article sans dévoiler les secrets de la construction à la concurence risque d'etre difficile.
Mais sinon en cherchant RISC/CISC sur google, on peut trouver quelques articles intéressant.
Comme celui ci sur les proc RISC de HP : http://www.cpus.hp.com/technical_references/parisc.shtml(...)
[^] # Re: article plus général
Posté par freePK . Évalué à 10.
Non. Pas libre ne veut pas dire ferme. Tout fait l'objet de depose de brevet et ces brevets sont publics (enfin, ceux que l'Armee ne censure pas ;-) ).
On peut tres bien faire un article dessus et expliquer tout le mecanisme. C'est l'implemantation qui est protegee. C'est tout.
PK
[^] # Re: article plus général
Posté par bertran dherouvi . Évalué à 1.
[^] # Re: article plus général
Posté par gui_ . Évalué à 3.
Contrairement à d'autre, j'aime bien que l'on me corrige, ça me permet d'apprendre (sauf que là, je connaissais la bonne orthographe, c'est plutôt de l'inatention).
Ce serait bien si certain pouvaient avoir un rôle de modérateur orthographique. Ils n'auraient pas le droit de toucher au contenu des commentaires, mais pourraient corriger les fautes.
Mais bon, qui à le temps de faire ça?
[^] # Re: article plus général
Posté par Aurélien Jarno (site web personnel) . Évalué à -4.
Bon aller -1 car HS.
[^] # [HS] Or tau Graff
Posté par feth . Évalué à 1.
Il arrive à quasiment tout le monde de faire des jeux de mots plus ou moins légers... sans compter l'emploi d'homonymes, de mots étrangers...
Une "revue et correction" effectuée par un autre que l'auteur risque à mon sens d'être très préjudiciable aux commentaires.
En revanche je trouverais chouette une moulinette facultative via aspell lors de la soumission d'un commentaire.
Encore mieux si cette moulinette proposait la francisation des termes techniques pour lesquels un équivalent technique existe !
I set to -1 because the post is off topic.
[^] # "Hack en C" ? et +
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Sinon Personne n'a de points particuliers à soulever ? Je pourrais en remettre une couche dans un prochain article sur tous ce que je n'ai pas mis dans celui-ci ? ;p
Sinon merci à tous pour vos remerciements, j'ai les chevilles qui vont exploser.
"La première sécurité est la liberté"
[^] # franchement...
Posté par blackshack . Évalué à 2.
[^] # dégonflage de chevilles
Posté par Yann Guidon (site web personnel) . É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)
[^] # vi
Posté par Denis Bodor (site web personnel) . Évalué à 2.
[^] # Re: vi
Posté par Yann Guidon (site web personnel) . Évalué à -1.
Tu veux parler de celui sur VHDL ou sur la DCT ? pour info, ça risque pas pour la DCR car j'ai pas encore fini le code (il faut tout vérifier, une erreur arrive si vite) et il faut encore réécrire tout le texte en français. Quant au code, il y a beaucoup de redondances car je montre toutes les étapes de la transformation, alors il ira sur le CD
Ah oui j'oubliais, il faut faire qqs illustrations, donc je dois prendre mon tgif pour dessiner au moins le graphe de dépendances de données...
[^] # Re: article plus général
Posté par a_jr . Évalué à 10.
Moi aussi.
D'autre part, ce qui manque a un tel article, c'est une sorte de glossaire. Les termes sont expliques, mais quand on est 2 pages plus loin et qu'un terme revient, on hesite a revenir 2 pages en arriere pour relire la signification du terme dont on n'a pas retenu la signification.
D'autre part, et ce serait tres en relation avec Linux ou Hurd, ce serait interessant d'avoir un article sur les pilotes du noyau. Non pas la vision du programmeur (quoique, y'a deja eu un article comme ca, et un autre ne serait pas de refus), mais la vision d'un gars en microelec.
Un truc interessant serait aussi une rubrique de bricolage, a savoir realiser puis brancher un thermometre sur linux, ou un detecteur de n'importe quoi. Je suis sur que de nombreux hackers s'amuseraient comme des fous si on leur fournissaient la maniere de creer un emetteur/recepteur infrarouge simple, pour apres commander la tele ou le lecteur video via linux, voire faire du reverse-engineering sur le protocole de communication du telephone portable. Sans oublier ceux qu'ont une calculatrice evoluee...
Le bonjour chez vous,
Yves
[^] # Re: article plus général
Posté par Yann Guidon (site web personnel) . Évalué à 4.
[^] # Re: article plus général
Posté par Xavier B. . Évalué à 5.
Hein, je ne suis pas le seul ?
Hého ?
[^] # Re: article plus général
Posté par Yann Guidon (site web personnel) . Évalué à 0.
</déconne>
[^] # un projet sous le coude
Posté par Denis Bodor (site web personnel) . Évalué à 3.
les chip USB, des 68hc11, des PIC, plein de petites pupuces qui parles a linux :)
Allez hop, des idees, des contribs, des voeux :
elect@linuxmag-france.org
et zou :)
Note : attention, soyez gentils, je suis aussi bon en electronique qu'en orthographe (sauf qu'en electronique en confondant vcc et vss ca coute plus cher)
[^] # Re: un projet sous le coude
Posté par Yann Guidon (site web personnel) . Évalué à 3.
je confirme. c'est comme ça que j'ai réussi à faire parler un afficheur LCD. Pas très longtemps mais il a dit "crrcrcrsrrc".
Pour ceux qui s'ennuient, je conseille : une pile 9V et un tas de DEL. prendre une DEL, la mettre aux bornes de la pile, reprendre une autre DEL...
</poésie>
# article
Posté par johann berchet . Évalué à 10.
Ce que je n'ai pas compris sur le F-CPU à part que c'est de la theorie est:
Qui pourrait s'intéresser à lancer ce CPU vu le prix que coute une ligne de fabrication (plusieurs milliards)
AMD? intel? motorola?
A quoi ça leur servirais vu qu'ils ont déjà une techno plus avancée et de la R&D béton?
Ou alors ça permettrais à vivendi-universal de se lancer la dedans? (pour devenir maitre du monde)
Y'a un gars qu'a inveté le moteur à eau mais je le vois pas dans les voitures?
Désolé y'a pas que l'argent qui compte , l'innovation c'est bien mais tant que ça resteras theorique....
[^] # Re: article
Posté par freePK . Évalué à 10.
Tu n'as pas tout compris.
Une ligne de fabrication coute en effet fort cher mais uniquement a developper. Une fois l'usine en place (on dit fab dans le jargon), la technologie (on la definit par l'unite de la chose la plus difficile a produire - a savoir la largeur de grille du transistor - comme 0.18 micron ou 0.13 micron), il ne reste plus qu'a produire pour rentabiliser l'ensemble.
Tous les fondeurs procedent ainsi. Ils delivrent une sorte de cahier des charges de leur techno (on parle de DRM pour Design Rule Manual), ils offrent des bibliotheques de cellules standard (portes elementaires, pads, cellule analogique, memoires, etc.) et tout le monde peut fabriquer un circuit a partir de ces donnees chez eux.
Combien cela coute-il ? Techniquement parlant - hormis les couts de developpement du circuit ici assume par des volontaires - le cout du produit s'etale ainsi :
- prix des masques
- prix de revient
Le prix des masques est celui de chaque niveau du circuit dans la techno specifiee (la technique de fabrication d'une puce consiste a empiler successivement un certain nombre de couches (basses comme le silicium et hautes comme les metalisations). Le prix de ces masques depend de la taille du circuit et de la techno : plus elle est fine et plus les masques coutent chers. Pour une techno de l'ordre de 0.18 um et pour un circuit de l'ordre du fcpu, il faut compter entre 100 000 et 300 000 dollars.
Pour le prix de revient, il est evident que le fondeur ne va pas te faire le meme prix pour 10 pieces et pour un million. Il y a des tonnes de parametres qui entrent aussi en jeu : temps de fabrication, rendement par tranche (on dit waffer), temps du test de validation fonctionnelle, prix du boitier, etc.
Du temps du pentium (enorme puce dans la techno d'alors), on parlait d'un cout de production de 85 dollars par piece. Le fcpu etant beaucoup plus petit, on peut esperer descendre de beaucoup ce prix.
Voila pour les couts : ce n'est pas faramineux meme si cela reste cher pour le particulier.
Quant a la philosophie de la chose, Nico te repondra mieux mais en gros, le domaine du hardware est bien pire que celui du software. Quand un produit coute 100 $, il y a grosso modo plus de 80% de royalties a verser a differents possesseurs de licences.
Exemple : dans un decodeur satellite (un SoC typique dont parle Nico dans son article) : il y a un decompresseur MPEG2 (au moins une licence), la gestion du son (dolby, surround, etc. au moins une douzaine de licences), l'algo de cryptage et de decriptage (pareil), etc. Quand on fait le calcul a la fin, c'est faramineux !
D'ailleurs, si vous voulez devenir riche, il suffit d'une bonne idee brevetee. C'est tout.
L'idee du f-cpu est de pouvoir utiliser le f-cpu comme entite (on dit macro) dans un SoC sans avoir a debourser de royalties... et ainsi, en generalisant le systeme, arriver a des SoC a prix tres reduits.
PK
[^] # Re: article
Posté par Jak . Évalué à 10.
Cyrix, par exemple, avant d'être racheté par National SemiConductor, n'a jamais fait autre chose que de la conception de puces. IBM était un des fondeurs, mais il y en avait d'autres.
Là, en effet, quand le projet F-CPU sera fini, n'importe qui pour utiliser les schémas pour vendre son propre processeur (tout en respectant la licence). F-CPU. Il faut admettre que cela demande de gros investissements contrairement au logiciel, ça risque de coûter un peu cher au particulier de faire fondre sa propre puce (mais c'est possible aussi).
Le processeur F-CPU aura beaucoup plus de mal à percer face à AMD, Intel, Motorola, IBM, HP que Linux face à Microsoft, AIX, HP-UX... Mais ce n'est pas le but non plus.
Je pense que le 1er intérêt du F-CPU, une fois finalisé, sera d'offrir à coût réduit un core processeur générique pour les PME/PMI qui pourraient avoir des besoins en circuits sans avoir à payer une licence à ARM, Intel, XIlinx. Il ne pourra commencer à apparaître que dans des circuits spécialisés avant d'être reconnu comme processeur générique, selon moi.
La route sera longue et difficile, je souhaite bonne chance à tous les participants!
[^] # Re: article
Posté par spim . Évalué à 1.
Au hasard Thomson ;-)
[^] # Re: article
Posté par freePK . Évalué à 5.
En fait, il s'agissait du coeur 486 pour la production. Le coeur Pentium n'a servi que pour calibrer la Fab de Crolles en Isere.
PK
[^] # Re: article
Posté par Raynaud Alain . Évalué à 3.
>es besoins en circuits sans avoir à payer une licence à ARM, Intel, XIlinx. Il ne pourra commencer à apparaître que dans des circuits spécialisés
>avant d'être reconnu comme processeur générique, selon moi.
>La route sera longue et difficile, je souhaite bonne chance à tous les participants!
On est franc? N'importe quoi. Une license ARM coute moins cher que le masque pour aller chez son fondeur.
Donc tout ton exemple s'ecroule: si tu prends un F-CPU (libre), et tu le fabriques, tu payes un ticket d'entree de $300,000 pour les masques (ca depend de la technologie).
Alors l'idee que ca permet de court-circuiter une license pour un CPU synthetisable, ca me fait doucement rigoler.
Alain.
[^] # Re: article
Posté par freePK . Évalué à 4.
Alors l'idee que ca permet de court-circuiter une license pour un CPU synthetisable, ca me fait doucement rigoler.
C'est parce que tu n'as pas tout compris ;-)
Le ticket d'entree dont tu parles est le meme pour tous... Si on fait un circuit, on paye tous cela.
Maintenant, sur ce circuit, tu mets un coeur ARM ; tu payes toujours ton ticket d'entree mais tu ajoutes le prix du coeur ARM (qui coutent tres cher a la difference de ce que tu dis). Si tu ajoutes une demi-douzaine de macros sous licence, le prix du ticket d'entree peut facilement se voir multiplier par dix...
300 000 dollars est encore assumable par une PME solide. 3 millions de dollars l'eliminent d'entree.
L'interet est donc bien de fournir des macros libres...
nota-bene : dans la vie d'un produit un peu long, le cout final du produit est tres peu impacte par les couts de developpement et surtout ceux des masques. Mais pour dix produits developpes, un seul a vraiment du succes. Il faut donc amortir les cout des autres...
[^] # Re: article
Posté par Jak . Évalué à 1.
Mais je pensais à l'achat de core déjà fait, par exemple le core PCI de chez Xilinx, qui n'est pas donné. Et il doit même exister des core ARM pour XIlinx à acheter également, et ça m'étonnerait que ce soit donné. Parce que l'on peut, dans certains cas, vouloir utiliser en production des FPGA plutôt que des ASIC, il commence à y en avoir qui sont adaptés à ça.
Et gagner quelques ? par pièces, ce n'est jamais négligeable.
[^] # prix d'IP
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: prix d'IP
Posté par Jak . Évalué à 1.
[^] # Re: prix d'IP
Posté par Raynaud Alain . Évalué à 1.
Un bon processeur RISC, ca se trouve a moins de $200,000. ARM, MIPS/Lexra, Arc Cores... Donc toujours bien moins que les masques ($500,000), et en plus tu peux amortir ta license sur plusieurs projets (je n'irais pas jusqu'a dire qu'il a 1 chip sur 10 qui reussit a se vendre, mais si c'etait le cas, tu aurais donc 5 millions de couts de masques, toujours pour $200,000 de licenses).
Ceci dit, c'est sympa de se fatiguer a faire des coeurs libres, ca manquait. Mais ne faites pas l'erreur de viser le processeur de station de travail, ca n'interesse en fait que les geeks soft qui ne comprennent pas l'absurdite du projet. Faites de bon coeurs: micro-controlleurs petits et efficaces, traitement du signal pour telephone GSM, cable modem, que sais-je... Des coeurs qu'on peut melanger dans un chip pour faire un systeme complet (SoC).
Alain.
[^] # ====> Moment <i>je pète un plomb</i> <====
Posté par Yann Guidon (site web personnel) . Évalué à 1.
je sais que tu ne le pensais pas comme ça en l'écrivant mais ...
Ceci dit, c'est sympa de se fatiguer a faire des coeurs libres, ca manquait. Mais ne faites pas l'erreur de viser le processeur de station de travail, ca n'interesse en fait que les geeks soft qui ne comprennent pas l'absurdite du projet. Faites de bon coeurs: micro-controlleurs petits et efficaces, traitement du signal pour telephone GSM, cable modem, que sais-je... Des coeurs qu'on peut melanger dans un chip pour faire un systeme complet (SoC).
mon sang n'a fait qu'un tour. J'ai même cru que c'était un apât à troll. Comme disait Kadreg, c'est trop gros mais ça explique pourquoi j'arrive pas à l'avaler.
Phrase #1
* ce n'est pas le seul coeur libre et il en existe de nombreux et qui fonctionnent déjà. Voir dans les facs, sujets de doctorat divers, opencores.org, opencollector.org... là où F-CPU frappe (à faire en mal) c'est sur "l'ambition". Le but est justement de faire sauter les limitations existantes, sur l'extensibilité du code et sur la modernité de l'architecture (ce n'est pas un Nième clone MIPS/DLX/SPARC...)
Phrase #2
* on fait l'erreur qu'on veut bien faire et quand on s'en rend compte, on assume. Et si on veut faire un CPU de station de travail, on le fait (cf 3)). Merci pour les "geek soft qui n'y comprennent rien à l'absurdite du projet" qui essaie juste de leur rendre la vie plus surmontable et de répérer les erreurs des pauvres ingés sous-payés d'Intel (c'est même pas de l'ironie, voir http://www.faceintel.com/(...)). D'après toi si autant de "geek soft" sont intéressés (le projet serait mort sinon) c'est parcequ'ils en ont marre d'être considérés comme des "cons de geeks" par "ces multinationales qui pensent ce qui est préférable pour nous". On dirait que tu n'as jamais eu affaire à un service de support informatique, ce qui est faux, puisque tu bosses à Tensilica. Mais justement, comme tu es dans une boite, tu peux presque parler d'égal à égal avec une autre boite, pas comme tout le monde. Bienvenue dans le monde réel.
Phrase #3 : là c'est le ponpon. Je me serais tu si il n'y avait pas celle-là.
* Non mais tu vois un "geek" (même non soft) faire du DSP pour GSM dans son garage ? pourquoi pas le convertisseur AD RF pendant que tu y es, avec une chambre à épitaxie près de le machine à laver ? J'en ai rien à battre et je fais ce qui m'intéresse. Sans oublier qu'avec la guerre des brevets constante et navrante entre tous les fabricants, la situation de ce milieu PUE et n'est pas près de devenir vivable avant 10 ans (pour les téléphones portables). Et puis il y a suffisamment de grosses et petites compagnies pour saturer le marcher et forcer les prix à la baisse, ce qui (à part la fragmentation du marché et l'incompatibilité et la fermeture des appareils et formats) justifie d'attendre avant de nous jeter dans l'arène en brandissant la GPL.
Phrase #4 : la petite couche de finition...
* Le terme SoC n'existait pas quand F-CPU a été créé. On appelait plutôt ça un "microcontrôleur" ou à la rigueur un "système intégré" mais maintenant on nous met du "SoC" à toutes les SoCes. Et puis vous imaginez quoi faire avec ? F-CPU est un microprocesseur, point barre. Il est fait pour en faire ce que vous voulez dans la limite des termes de la GPL et de la charte F-CPU.
Le message est : on ne fait pas F-CPU pour épargner le boulot des grosses boites et leur offrir gratuitement du travail prémaché. Je sais qu'il y en a qui se l'imaginent, mais tant qu'à le faire, autant se faire payer. J'ai eu un mal fou pour arriver à faire comprendre à Michael Riepe, le contributeur pour les unités critiques, d'assouplir légèrement ses conditions de licence. Mais faut pas pousser de l'autre côté non plus ! F-CPU est fait par et pour les utilisateurs, pas pour le bon plaisir de ceux qui le récupèrent.
Y'a pas marqué "BSD".
[^] # Re: article
Posté par gilles renault (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: article
Posté par LeMagicien Garcimore . Évalué à 1.
De plus, niveau vitesse, c'est pas le pied :)
[^] # Re: article
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: article
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
Envoyé depuis mon PDP 11/70
[^] # Re: article
Posté par Jak . Évalué à 3.
Le problème, comme cité plus haut, c'est le coût et les performances du truc. Ça sert à tester un prototype, moins souvent à la production (encore qu'il y en a qui sont faits pour ça, voir les Spartan par exemple).
Là, un Xilinx ne servirait qu'aux prototypes. Et c'est pas sûr que ce serait bien utile. En plus, les logiciels pour le programmer sont assez chers, le bas de gamme étant Fondation qui ne tourne que sous Windows ou HP-UX (à moins que ce soit Solaris au lieu de HP-UX... je sais plus).
C'est un autre problème du projet : les outils de développement libres ne sont pas aboutis pour le moment, il faut qu'ils utilisent ce qu'ils ont à disposition (en École ou en université, ça doit se trouver), mais ce n'est pas toujours évident.
(Même en étant malhonnête par nécessité, on ne trouve pas de version pirate :) , donc c'est sans objet. Encore que si on utilise leur logiciel (je parle de Fondation), c'est qu'on va leur acheter des composants => c'est même limite défendable).
[^] # Re: article
Posté par Yann Guidon (site web personnel) . Évalué à 1.
Comme tu le dis, à quoi ça servirait si en plus il faut payer le Spartan ?
Pour l'instant on privilégie la portabilité du code. On fait de la compilation/simulation pure en VHDL'93 standard et sans chichi, en utilisant Vanilla VHDL et surtout Simili de http://symphonyeda.com/(...) qui permet de prendre son pieds même sous Linux.
Ainsi, le source (comme celui de Linux et autre GNU) peut être utilisé partout où la norme VHDL'93 est décemment respectée (détail important, puisque je suis en DEA au département ASIME où est conçu Alliance [ voir http://asim.lip6.fr/alliance.html(...) ] qui n'est pas ce qu'on pourrait appeler la panacée de la compatibilité et du workflow propre).
Par contre Cadence nous permet d'utiliser gratuitement ncsim. Encore eusse-t-il fallu que je trouvasse le temps de lire leur doc (50MO, ça dit qqn ?)
[^] # Re: article
Posté par Jak . Évalué à 1.
Ben, ce que je veux dire, c'est qu'ils pourraient filer ça gratos plutôt que de le faire payer, puisqu'en sortie on ne peut cibler que leurs produits.
Alliance, j'avais un peu regardé, il y a longtemps, j'avais dû faire les tutoriels, et je m'étais un peu amusé avec les générateurs de multiplicateurs. J'en avais même compilé un avec le compilo de Synopsys (c'était sur HP-UX). La simulation marchait, par contre, je crois pas qu'il était synthétisable.
[^] # Re: article
Posté par Yann Guidon (site web personnel) . Évalué à 2.
Alliance est inutilisable dans un workflow à la fois simple et standard. Pour cela je préfère Simili pour la simulation car il ne souffre pas des mauvais choix de programmation de l'équipe CAO d'ASIME. Vous connaissez le coup du malloc spéculatif ? http://tnemeth.free.fr/fmbl/linuxsf/41-1.html(...) Il y a des fois où je crois qu'il a été inventé ici ...
Pour ce qui est des générateurs, on ne peut même pas les utiliser : F-CPU a des contraintes trop fortes, principalement le pipeline dont le chemin critique fait environ 6 portes logiques à 4 entrées. Un allemand (Michael Riepe) nous a concocté quelques unités d'exécutions de la mort : additionneur 64 bits à deux étages et MAC 64*64+64 à 8 étages ! (6 étages en 2*32 bits en parallèle (SIMD), 4 en 16 bits...).
Par contre ce qui fait vraiment chier c'est pour avoir un bon synthétiseur LIBRE et c'est pour ça que Alliance, malgré tous ses gros défauts, restera une alternative de dernier recours si on arrive pas à se débrouiller. Pour cela il faudra "sauter" l'étape de synthèse et attaquer directement au niveau netlist. Par contre, même si la librairie de cellules logiques d'ALLIANCE semble convenir (ses règles de dessin devraient passer dans toutes les fonderies), ses performances sont relativement ... indéterminables.
Bienvenue dans le monde libre.
YG (tiens je suis maintenant à 19 XP ???)
[^] # Re: article
Posté par Jak . Évalué à 2.
À l'époque, je crois même que c'était écrit qu'on ne pouvait travailler qu'en comportemental, donc la synthèse, c'était si on avait de la chance :)
YG (tiens je suis maintenant à 19 XP ???)
20 même :) <avis perso>De toute façon, vu que la plupart votent n'importe comment, ça correspond pas à grand'chose. Ah, si ! Ça sert à faire des concours de quéquettes sur la tribune :) </avis perso>
[^] # Re: article
Posté par Yann Guidon (site web personnel) . Évalué à -2.
hmmmm je préviens les autres moules qu'il y a un joli début de troll par ici ? :-)))
[^] # debut de troll ?
Posté par kadreg . Évalué à -2.
[^] # Re: debut de troll ?
Posté par Yann Guidon (site web personnel) . Évalué à -2.
moui c'est ça : avec kadreg dans le coin, ça va bientôt faire ====>pika<==== partout...
[^] # Re: debut de troll ?
Posté par gle . Évalué à -1.
Pika !
Rien à foutre des XP, comme disait l'autre !
[^] # Re: debut de troll ?
Posté par Antoine Beck . Évalué à -2.
[^] # C koi ce nick
Posté par cedric . Évalué à 1.
[^] # Re: article
Posté par Ronan BARZIC . Évalué à 1.
Heu... tu serais surpris du nombre de problemes que l'on voit apparaitre en faisant des protos FPGAs avant de fondre un asic.
Croire que la simulation suffit, c'est aller droit dans le mur, au vue du prix d'un jeu de masque.
Et meme si un FPGA ca ne pedale pas rapidement, ca pedale toujours plus vite
qu'une simu logicielle (booter Linux en simu soft : bonjour - en FPGA, Intel l'a deja fait...)
Ronan
[^] # Re: article
Posté par Yann Guidon (site web personnel) . Évalué à 1.
Pour ce qui est d'un "bug killer", j'essaierai de reprendre contact avec mon ancien employeur qui fait des FPGA très ... spéciaux. RV à DATE2002 sur le stand Mentor, près de la machine qui ressemble à une méga-photocopieuse :-)
[^] # Re: article
Posté par Jak . Évalué à 1.
[^] # Re: article
Posté par Yann Guidon (site web personnel) . Évalué à 1.
Je ne sais pas exactement, on ne peut pas savoir tant que le coeur n'est pas terminé. on en est au 1/3 ou au 1/4 pour l'instant (estimation au pif).
pour estimation, la synthèse du multiplieur a donné plus de 4096 bascules. Rajouter 4096 bits de mémoire multiport (3R2W) pour le banc de registres. Ajouter la cache L1 (split data+instruction, 256 bits par ligne). Ajouter les LSU et le fetcher (256*8 bits mutliports chacun). Ajouter environ une 50aine de buffers 64 bits pour différents étages du pipeline...
Voilà pour la partie "mémoire". Pour la partice combinatoire, il faut compter environ 6*64 portes logiques par étage de pipeline.
Une estimation à la louche me dit qu'il est possible de faire tenir FC0 en entier sur une CELARO à 1 cabinet avec une quinzaine de cartes "accélération" et une ou deux cartes S(D)RAM pour stocker les programmes. Comme on est en superpipeline, la machine tournera à vitesse maximale. Avec un peu d'astuce on peut même "mapper" certaines fonctions comme le Xbar sur le fond de panier. Mais certaines fonctions sont difficiles à mapper, comme le banc de registre qui utilisera probablement une carte entière... Bref, j'ai eu 6 mois pour réfléchir à ce sujet et ça me botte toujours :-) Il y a d'ailleurs un screenshot qqpart qui montre que j'ai "émulé" l'unité logique à 6MHz il y a plus d'un an...
YG qui a dormi 3h cette nuit !!! houra :-)
[^] # Re: article
Posté par Jak . Évalué à 1.
Ah, oui, quand je dis que ça ne serait pas bien utile, en fait, je me disais qu'il risque d'y avoir besoin d'un FPGA très gros, avec énormément de portes, ce qui risque de coûter extrtêmement cher, d'où problème.
Donc cette étape ne sera probablement pas faite directement par les contributeurs dans leur garage.
[^] # et en plus il faut des machines surpuissantes...
Posté par koopa . Évalué à 1.
Même un PC dernier cri (genre P4@2Ghz), gonflé à bloc au niveau de la mémoire (4Go) me semble un peu juste pour simuler/synthétiser une puce aussi complexe qu'un microprocesseur.
.
L'EDA (Electronic Design Automation) est un des domaines d'application qui consomme le plus d'espace mémoire et de CPU. (pour le plus grand bonheur de Sun Microsystem, qui a la majorité de ce marché).
[^] # Re: et en plus il faut des machines surpuissantes...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Simu porte cela se gate un peu mais c'est bon !
synthèse : glurps ! >1Go/Ram juste pour le multiplier : on évitera la compile top-down !
"La première sécurité est la liberté"
[^] # Re: article
Posté par Raynaud Alain . Évalué à 1.
Ce n'est pas du RE-programmable. Mais c'est encore mieux!
Au lieu de concevoir un processeur RISC (a la F-CPU), on a ecrit un generateur de processeurs. Tout le processus est automatique: tu decris dans notre propre langage ton processeur ideal, tu cliques sur "Build", et une heure plus tard, tu recois tout ce qu'il faut pour le fabriquer.
L'avantage de cette solution, c'est que pour un algorithme donne, on explose tout le monde en performance. Par exemple, une societe veut faire une camera numerique: ils leur faut un compresseur JPEG. Avant qu'on arrive, tout ce qu'ils pouvaient faire, c'est acheter le plus DSP de chez Texas Instrument, et soufrir a cause de la consommation monstrueuse. Ou alors concevoir une cellule custom pour JPEG, perdre 1 an par rapport a leurs concurrents, et tout mettre a la poubelle le jour ou JPEG2000 est arrive.
Maintenant, en creant leur processeur "customise" pour JPEG, ils gardent les avantages d'un processeur, c'est souple, on suit facilement les changements de normes, etc... et ils ont essentiellement la performance d'une cellule custom. Conso tres reduite egalement, donc ta camera a une autonomie doublee.
Ca s'applique aussi pour les set-top-box MPEG2, les decodeurs AC-3, les routeurs et autre hub TCP/IP, etc...
Alors oui, le seul cas ou ca marche pas, c'est 10% du marche des processeurs, a savoir les processeurs de bureau (Intel x86, PPC). Quoi que. En tout cas, le concept d'un meta-langage de description de processeurs, c'est autrement plus cool que de se prendre la tete sur un seul processeur!
Et en plus on a le plaisir de travailler dans une startup...
# pas clair pas clair du tout; pour l'instant...
Posté par mathic . Évalué à 1.
Pourtant je travaille un peu sur la programmation de µps simples (8051, 68HC11). Donc j'ai une connaissance qui est vraiment de "base" sur le fonctionnement d'un µp, mais là !!!!
C'est trop durt, j'ai travallerais plus en profondeur plus tard !!
# Très interessant
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
Je l'ai trouvé très interessant car tu parles aussi des technos que vous avez choisi de ne pas utiliser et en expliquant brievement pourquoi.
Par contre, je pense que cet article n'est pas totalement compréhensible par quelqu'un qui n'y connait rien.
Exemples:
- le SIMD
Tu dis ce que c'est Single Instruction Multiple Data et que ca veut dire qu'il y a des fonctions similaires au SSE, SSE2, MMX, 3DNOW et plus loin que ca augmente le CPI.
Tu ne dis à aucun moment ce qu'est une instruction SIMD. par la suite tu dis que le decodage est le meme at qu'il suffit de dupliquer les unités de traitement mais si on ne sait pas ce qu'est le SIMD on ne comprend pas trop.
- le CISC et le RISC
Tu aurais pu expliquer en une phrase la difference.
Je ne vais pas relire tout l'article à la recherche de choses non expliquées bien que je pense qu'il n'y en ait pas tant que ca.
Je pense que quelques petis exemples pour ces points auraient rendu ton article plus accessible sans pour autant l'alourdir.
Pour conclure félicitations pour ton article que je trouve globalement très bien et qui m'a donné envie de suivre le F-CPU de plus près.
[^] # Re: Très interessant
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Concernant RISC et CISC, ... ce que l'on dis actuellement est faux (un cycle par instruction (3 pour la fpu Sparc), nombre d'instruction réduit (+ de 300 parfois), nombre de mode d'adressage réduit).
La seul chose qui soit vrai est la taille fixe des instructions pour simplifier le décodeur.
Concernant la compilation SIMD, si tu pouvais fournir de l'aide au projet Gcc, cela sera toujours utile au Fcpu dans le future.
"La première sécurité est la liberté"
[^] # Re: Très interessant
Posté par freePK . Évalué à 4.
La seul chose qui soit vrai est la taille fixe des instructions pour simplifier le décodeur.
C'est faux actuellement mais c'est parce que le nom n'a pas change depuis la creation de la bete... A l'origine, c'etait vrai bien sur...
C'est comme dire qu'aujourd'hui le x86 est un CISC... Cela n'a plus beaucoup de sens.
PK
[^] # Re: Très interessant
Posté par Ronan BARZIC . Évalué à 6.
Si ! Le x86 est toujours un CISC au sens de son "ISA" (instruction set architecture),
quand bien meme son architecture interne est "RISC".
On confond le concept du RISC et les caracteristiques techniques des implentations du dit concept
Un RISC, c'est d'abord une architecture Load/Store + un jeu d'instructions simple et orthogonal vis a vis des regitres.
En clair :
- il n'y a que des operations arithmetiques/logiques entre registres (la memoire n'est pas utilise)
- les acces a la memoires ne servent qu'a charger ou stocker des registres
- pas de registres specialises (du style accumulateur, pointeur de donnee, etc...)
- des instructions utilisables efficacement par un compilo (le plus important !!!)
Les autres soit-disantes "caracteristiques" d'un RISC (nombre d'instructions, nombre de cycle par instruction, mode d'adressage plus ou moins reduit, complexite du decodage, etc..), ce sont
les contraintes d'implentation qui les fixent (et le bon sens) .
Avec ces criteres, le x86 est bien un CISC et le restera jusqu'a la fin de sa vie....
Ronan
[^] # Re: Très interessant
Posté par Yann Guidon (site web personnel) . Évalué à -2.
/un CISC/de la merde/
[^] # Re: Très interessant
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
J'y ai pensé mais j'ai deja 50 trucs en cours et du temps pour aucun.
En attendant, si quelqu'un veut s'en occuper, il y a un gars au MIT qui a proposé un algo assez simple : http://www.cag.lcs.mit.edu/slp/SLP-PLDI-2000.pdf(...)
[^] # Re: Très interessant
Posté par Yann Guidon (site web personnel) . Évalué à 3.
mais j'ai survolé : ça m'a l'air que du bon !
merci pour le lien !
# Très (trops général)
Posté par Damien Merenne (site web personnel) . Évalué à 8.
Une suite de plusieurs article expliquant chacun un point bien précis sur les architectures: les bases, les interruptions, la mémoire virtuelle, les caches, les pipelines,... ca pourrait être très intéressant pour ceux qui n'y connaissent pas grand chose.
Merci quand même pour cet article que j'ai fort apprécié.
PS: il y a un cours d'architecture des ordinateurs disponnible à http://www.montefiore.ulg.ac.be/~pw/cours/struct.html(...)
[^] # Re: Très (trops général)
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je veux que chaque article se suffise (plus ou moins) à lui-même. C'est difficile mais avec l'exemple que tu prends, j'aurais passer l'année entière avec le même thème !
"La première sécurité est la liberté"
[^] # Re: Très (trops général)
Posté par Damien Merenne (site web personnel) . Évalué à 1.
# Bon bon bon
Posté par Vincent MOLLIMARD . Évalué à 6.
- les articles de presse n'ont pas la vocation d'un cours.
- les moteurs de recherche permettent de trouver les liens nécessaires à une explication complémentaire si nécessaire tout comme les références fournies dans le papier de linux mag
- bien que pas électronicien pour deux sous une lecture attentive m'a appris plein de choses.
- si le spécialiste reste sur sa faim, la liste de diffusion du projet lui est ouverte. J'ai d'ailleurs constaté que cela marche en allant y faire une petite visite
Bref j'ai pas tout compris mais à chaque fois que je relis l'article, j'ai l'impression d'être un peu moins c..
Merci Nicolas, c'est que du bon !
[^] # Re: Bon bon bon
Posté par Yann Guidon (site web personnel) . Évalué à 7.
moi qui suis considéré (par les autres) comme "l'organisateur" du projet (pasque j'ai les doigts qui ont de l'endurance et que ça fait maintenant 3 ans que je suis dans ce "radeau de la méduse"), ben j'apprends des choses tous les jours. Soit je les découvre, soit je les invente :-)
Par exemple, aujourd'hui, je me suis rendu compte qu'en utilisant une fonctionalité considérée comme "optionnelle" (le fabricant peut implémenter l'instruction ou la simuler par soft), on peut réduire jusqu'à 90% la taille des tables en ROM destinées à l'autotest de la puce... dingue :-)
Et pour ceux qui ont pas trouvé le lien sur notre site crade (webmaster wanted), vous pouvez vous abonner sur le site web de l'APRIL à http://lists.april.org/wws/info/f-cpu_france(...)
bien que les discussions techniques se passent sur la liste anglaise ( http://archives.seul.org/f-cpu/f-cpu/(...) )
Pour le reste, j'ai bien lardé cette page avec plein d'autres URL... 'a ka lire :-)
# Un bon article
Posté par reno . Évalué à 1.
1) Sur le plan technique juste une petite remarque pourquoi avoir utilisé le terme "diélectrique" au début de l'article plutôt que "isolant"?
C'est la même chose, non?
2) Sinon il y a un truc que je n'ai pas bien compris c'est le positionnement du FCPU.
Au début de l'article, tu parles du créneau du maximum de puissance pour un coût minimum.
Et après c'est un CPU 64 bits superpipeliné, incluant le controleur de mémoire, le controleur DMA, le controleur de bus périphérique (le southbridge ?????).
Haute performance peut-être, mais surface de silicium mmmh intéréssante on va dire!
Bon peut-être que le bas cout va venir du fait que le code VHDL sera libre..
3) En plus j'ai un gros doute sur l'interet de mettre le southbridge dans le CPU: les standards evoluent tellement rapidement..
4) Je suis d'accord avec le débat du dessus qui considere que la bataille d'architecte a été considéré du mauvais point de vue: CISC ou RISC ce sont des differents type de jeux d'instruction (IS: Instruction Set) sous-entendu jeux d'instruction EXTERNE..
Et pour moi:
- le CISC a gagné la bataille pour les PC car le 80x86 a gagné la bataille et que la compatibilité ascendante s'est avérée plus importante que la performance pure.
- le RISC a quasiment gagné tout le reste des autres segments.
5) Il est marqué aussi: chaque instruction peut traiter un nombre unique ou un paquet composé de nombre 8,16,32,64 bits.
Ca veut dire qu'a chaque instructions, il y a 3 bits qui indiquent le type de l'instruction?
Mmm, je crois que je vait regarde sur le web..
[^] # Re: Un bon article
Posté par Yann Guidon (site web personnel) . Évalué à 1.
1) ça montre qu'on est du "milieu" :-)
2) positionnement : l'un et l'autre ne sont pas incompatibles.
quoique pour l'instant, le ctrl DMA et quelques autres accessoires soient un peu en dehors du but central du projet.
D'ailleurs, on en a très peu discuté, ce qui empêche quiconque de s'avancer.
Pour ce qui est de la surface : il y a des arguments pour et contre un circuit large.
- d'un côté les transistors et les fils deviennent de plus en plus petits, et surtout presque la moitié des transistors servent à latcher des données entre deux étages de pipeline.
- de l'autre côté plus un circuit est petit et plus il peut aller vite et être moins cher (cf ARM). Sans parler du débogage.
Pour sûr FC0 (l'implémentation en cours de réalisation) sera un terrain de foutebaule comparé à un ARM à technologie égale. Mais la comparaison s'arrête là : d'abord c'est du 64 bits avec 64 registres, la fréquence visée est plus grande (il faut 2 cycles pour une adition), les buffers mémoire sont différents...
Donc à chacun de voir, et en plus F-CPU est même fourni avec les sources, donc chacun peut tourner les boutons dans le sens qu'il l'entend : enlever des unités inutiles, changer la taille des registres et des unités, ...
Et puis à quoi bon comparer puisque les intentions sont complétement différentes ?
3) c'est vrai que ça va vite, mais un des seuls avantages du PII par rapport au P5 est qu'il a un bus séparé pour accéder à la L2 externe. Associé à un algo de préfetch dont j'ai eu l'occasion de juger de l'efficacité, j'ai été bluffé du speedup. Le but est de faire ça avec la RAM externe "privée" afin de 1) raccourcir et accélérer les transferts entre le coeur et la RAM offchip 2) bénéficier des "stream hints" inclus dans le code, au lieu de dépenser du HW et du développement dans une machine à reconnaitre les flux de données.
4) j'en ai rien à foutre aujourd'hui : je bosse sur F-CPU qui est descendant des RISC.
5) tout à fait : 1 bit pour indiquer si c'est SIMD et 2 bits pour dire la taille. c'est présent dans toutes les instructions qui opèrent sur des données et c'est bien pratique :-) En changeant la signification des 2 bits de taille on peut faire du code en largeur 128 256 512 1024....
ça change de ces putains d'extensions et de préfixes qu'on trouve dans d'autres architectures (hmmmm.... non.)
Pour le web, voir les urls présentées précédemment.
[^] # Re: Un bon article
Posté par reno . Évalué à 2.
Mais dans l'article, il etait aussi decrit l'integration du controleur bus peripherique dans le FCPU.
Moi j'interprete ca, comme etant l'integration du southbridge dans le CPU ce qui me parait un peu bizarre..
Vous voulez vraiment integrer un controleur PCI, USB, Firewire, ISA(:-)) dans le CPU?
[^] # Re: Un bon article
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
nicO
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.