En lisant le manuel de l'ISA de RiscV, j'arrêtais pas de me dire "Mais WTF ?" surtout à cause des formats d'instructions super longues qu'il prévoit. D'un autre côté, on voit bien que l'expérience des générations précédentes a été très bénéfique, surtout pour la densité de codage, par exemple la réduction la taille des instructions "classiques" de 32 à 30 bits sans vraiment réduire l'efficacité.
Toutefois, je cherche les réelles innovations. RiscV est très "poli", soigné, mais reste à la base une évolution logique de premiers MIPS, une architecture qui a 30 ans maintenant. J'aurais aimé voir plus de remise en question de certains principes de base, par exemple les mécanismes d'accès à la mémoire (qui sont restés les mêmes depuis le tout début). Les techniques d'écriture ou de lecture de la mémoire, ainsi que les sauts de programme, posent des soucis qui font boule de neige lorsque le cœur grossit, causant des délais de toutes sortes et occupant encore plus de place dans les circuits (prédiction de branchement, logique pour flusher le pipeline…)
F-CPU a exploré une alternative, YASEP va encore plus loin. On est au 21è siècle ou pas ? Ah oui mais on reste encore cloués à des méthodes et outils des années 80-90…
Cela obligerait à s'investir dans une seule architecture propriétaire. Ce n'est pas bien pour la pérennité d'un projet. Pour libérer les utilisateur, il faut leur laisser le choix, donc leur permettre de passer d'une solution à une autre sans trop d'efforts.
Et puis on ne sait jamais ce qu'il pourrait arriver à la famille de puces qu'on a choisi. Il y a quelques années, la startup SiliconBlue avait sorti un FPGA sympa (bien que lent) et s'est faite racheter par Lattice, qui s'est empressé de jeter leur travail par la fenêtre. C'est mignon… Peu après, Actel s'est fait racheter par Microsemi et heureusement ils n'ont pas déconné avec, mais qu'est-ce qui les en aurait empêché ?
Aussi ce n'est pas dans les attributions du projet, qui est de concevoir un CPU et de libérer les utilisateurs. Et puis il faut choisir entre le reverse et la création. Il y a un projet qui a plus ou moins réussi à reverser (partiellement) un FPGA Xilinx mais idéalement, il faudrait (pour tout le monde) un FPGA Libre. Là, c'est un projet d'encore plus grande envergure que F-CPU…
Les cartes graphiques libres pour PC, effectivement, n'ont pas eu beaucoup de chance. Le seul truc à peu près valable a été opengraphics.org qui a fabriqué une belle carte à FPGA. Son générateur de timing programmable est une jolie invention.
Mais aujourd'hui le projet OpenGraphics s'est recentré sur https://github.com/jbush001/NyuziProcessor qui est un cœur de GPU open source.
Au fait il y avait un bruit comme quoi Samsung aimerait bien racheter AMD. De news à ce sujet ?
Pour les cartes low-cost avec un petit FPGA, c'est le YASEP qui convient. Il peut être configuré en 16 ou 32 bits et la densité d'instruction est meilleure, alors que le F-CPU est prévu pour des calculs sur 64 bits. Une telle largeur peut ralentir le CPU s'il faut passer par un bus mémoire plus étroit…
Au moins, en utilisant un environnement de conception unifié (pour configurer le matériel en fonction du code à exécuter, puis pour le simuler), l'architecture du cœur devient moins importante. Il sera bientôt facile d'essayer un morceau de code sur différentes architectures pour voir la taille du code généré, la vitesse d'exécution, les options à activer, les éventuelles extensions à créer… et juste avec des Logiciels Libres (car tout en Affero GPL V3, sauf les synthés proprios).
Ainsi ne se posera plus vraiment la question originale "Ce qui serait vraiment sympa, ce serait que le FCPU puisse tenir sur un XYZ". On code le cœur de l'application voulue puis on essaie avec différents paramètres (taille des registres, taille cache, type de cœur…), on simule, on profile, et on garde ce qui donne le meilleur encombrement de FPGA à performance donnée. Ou ce qui donne la meilleur performance brute. Ou ce qui consomme le moins. Ou…
Je suis une nouille, je ne trouve jamais la touche Meta sur mon clavier alors j'utilise nano ;-)
Mais effectivement, GHDL et GTKWave sont vraiment des outils indispensables. Ce que je conçois avec fonctionne souvent dès le premier coup quand je le mets dans un FPGA. Je fais souvent le parallèle entre GCC et GHDL, l'un ayant permis la conception de Linux, l'autre permettant des processeurs libres. L'un comme l'autre changent toute la donne.
Je bosse "officiellement" sur http://ygdes.com/WizYasep/ et fin 2015 j'aimerais avoir une 2è génération encore plus puissante. C'est grâce à ces projets que j'aiguise les outils pour le YASEP et F-CPU. J'ai utilisé l'environnement du YASEP pour réaliser un vrai projet pro et je vais continuer de l'améliorer car c'est vraiment pratique !
Mais pour l'instant, ce qui paie mes factures c'est des ptits jobs comme https://www.facebook.com/101308076630787/videos/848924055202515/ et je me bats pour concilier les développements pro et perso. Au moins ça reste dans mon domaine, mais ça me saoule d'avoir plus de réputation dans le domaine des LEDs que des microprocesseurs -_-'
Un F-CPU est quand même plus à l'aise avec plus de RAM et de bande passante. Par exemple http://m-labs.hk/m1.html commence à devenir confortable.
Actuellement je planche sur l'utilisation de http://emcraft.com/products/255 et un collègue prépare une version plus puissante (jusqu'à 4GB de DDR667). Là, ça commencera à devenir intéressant :-)
Je vois bien du côté du non-libre (e.g. ALTERA ou Xilinx), mais en libre?
Ah, j'ai dit "sous Linux", j'ai pas parlé de libre (omission stratégique).
On a attendu presque une décennie pour que les outils proprios daignent être portés presque correctement sous nunux…
Donc effectivement, un outil de synthèse-placement-routage libre est un des derniers points critiques pour que ce soit complètement libre. Il est envisageable de générer des .edif avec un synthé open source, un jour, mais tout le reste dépend réellement du fabricant du FPGA, c'est un domaine ultra-propriétaire.
La seule solution est de créer des FPGA "Libres". Mais là cela dépasse largement mes attributions.
En attendant, le "moindre mal" consiste à accepter un petit bout de propriétaire, à condition que 1) on ne peut pas faire autrement 2) on évite au maximum d'utiliser des features trop spécifiques 3) on peut passer à la concurrence sans effort. Tout cela fait qu'il est possible de basculer partie par partie vers du réellement Libre lorsqu'il devient disponible, sans que cela freine l'ensemble du projet.
Merci Pierre, j'apprécie beaucoup, et cela fait plus de 10 ans puisque F-CPU a participé à RMLL2002, donc il y a déjà 13 ans…
Concernant les cours/TP, j'y pense depuis longtemps. L'année dernière j'ai eu la possibilité de proposer des conférences pour une école d'ingés infos, mais le boulot m'a rattrapé et je me suis aperçu que je ne pouvais pas faire les deux à la fois, car je suis trop investi, surtout dans les sujets qui me passionnent. Les conférences étant non rémunérées, le choix a malheureusement été vite fait :-( Mais je ne perds pas espoir. Si c'est pour intervenir de temps en temps, et cela ne me prend pas trop de temps à préparer, je suis toujours partant.
Effectivement, quand on a la tête dans un truc, et durant un décennie en plus, c'est pas facile de tout expliquer car les référentiels sont parfois trop différents : c'est un peu comme expliquer comment administrer Linux à une personne qui n'a connu que du windows… Mais au moins j'essaie et déjà le fait que des centaines de personnes aient pu essayer et regarder est un grand pas par rapport aux formes "classiques" de projets open hardware. Je ne prendrai comme exemple que OpenCores qui nécessite un enregistrement (pour satisfaire les annonceurs publicitaires) puis l'installation d'outils… Combien vont jusqu'au bout ?
Ensuite c'est vrai que je suis un "technicien" et pas un "designer" et encore moins un expert en esthétique ou ergonomie. Cela permet d'explorer d'autres types d'interactions et je recherche de retours constructifs.
Je suis parti du principe que de nos jours, plus personne ne lit des manuels et préfère cliquer partout, ce qui a influencé la structure du site. Mais aussi, puisque je développe et même utilise cette interface depuis longtemps, je m'y suis habitué… Donc voilà, j'essaie de rapprocher les "référentiels" :-)
Actuellement je prépare la conférence qui contiendra des exemples, que j'inclurai ensuite dans un tutoriel un peu plus parlant. J'espère que cela aidera plus les "curieux" !
Ça tient de la poésie autant que du génie logiciel.
Je n'avais pas vu ça comme ça, plus comme "un truc de geek" :-P
L'unité, c'est la fusion de tout cela et de plus, et même un maximum. Certains éléments n'ont par nature pas de place dans le navigateur (l'interface matérielle surtout) mais tout ce qui peut y entrer y ira. En fait, plein d'initiatives de ce style voient le jour depuis plusieurs années (Chrome OS, Mozilla et son Boot To Gecko, et d'autres encore), et donc pour une fois je me retrouve à l'avant de la vague technologique…
Dans le site, il y a toute la gestion de la documentation, la gestion des E/S fichiers (les entrées sont à refaire mais on peut sauver des fichiers), les outils de programmation en assembleur, et plus tard en graphique avec GNL puis en textuel avec des frontends HLL pour générer du GNL à partir de C/Pascal/FORTH/ce qu'on veut…
Actuellement je travaille sur le simulateur. Il se repose à la fois sur l'assembleur, l'éditeur et d'autres fonctionnalités développées pour les autres fenêtres : plus on ajoute de fonctions, plus le développement des autres pièces est facile et l'ensemble gagne en utilité et puissance. Pour le F-CPU, tout était distinct et donc pénible et désynchronisé, là une petite modif, on sauve et on recharge la page : tout est mis à jour automatiquement. Ah oui, mes 2 outils sont nano et grep :-)
Donc le principe de l'unité c'est de faciliter le développement. Un peu comme Linux et le système GNU, qui ont été conçus pour un développement facile, conçus dans l'optique de leur propre maintenabilité, ce qui favorise le développement des versions et du contenu et forme un système auto-entretenu. L'inventaire de Prévert n'a pas de cohérence apparente ou directe, alors que chaque fenêtre ou module ajouté au site augmente son utilité et utilisabilité, sert à quelque chose et même est nécessaire.
Le principe c'est aussi d'éviter au maximum d'installer des outils externes. C'est l'un des freins majeurs pour l'adoption d'un nouveau système. Installer, adapter, configurer, apprendre à se servir de, puis faire communiquer avec des outils parfois disparates… Si tout est intégré, alors l'installation se résume à avoir un navigateur "correct" (plus un Apache+PHP pour certaines fonctions annexes, et qqs petits trucs que je prépare). Ce qui revient au mantra "utilité et utilisabilité".
Il y a encore 10 ans je voyais JavaScript comme une plaie à éviter à cause de toutes les failles de l'époque et sa lourdeur pour le CPU. Avec les multicores actuels et les optimisations dynamiques, la situation a radicalement changé : notre Bellard national boote Linux dans votre navigateur http://bellard.org/jslinux/ et les jeux prolifèrent (en commençant par http://www.elizium.nu/scripts/lemmings/ ) donc tant qu'on n'a pas besoin de l'ultime performance, pourquoi embêter les gens en les forçant à installer X ou Y, compiler Z et râler à cause de telle ou telle librairie ? Personne ne fait d'effort de nos jours donc l'accessibilité est cruciale pour que les gens commencent à explorer à leur manière : en cliquant.
Ensuite, quelques réponses plus directes :
à maturité, je pense que le microcontrôleur continuera d'être "packagé" avec l'interface. C'est modulaire donc on peut séparer des trucs sans rien casser, comme prendre le contenu du dossier http://yasep.org/VHDL/ pour ne garder que les sources VHDL, ou récupérer YGWM pour faire d'autres sites (Laura utilise déjà YGWM pour coder http://ygllo.com/~llo/MetaFor/code/page_centrale.html ) donc ça dépend de ce dont on a besoin. Mais le tout forme un ensemble cohérent et je ne vois pas d'intérêt à découper.
Je ne suis pas sûr de comprendre ce que "son architecture finalisée" veut dire. Une architecture évolue naturellement, et avec un toolkit comme celui-ci, encore plus vite :-)
Qu'est-ce qu'on programme sur un microcontrôleur ? plein de choses… Par exemple le YASEP a eu un coup de boost lorsque j'ai songé l'utiliser pour un gros projet, où il aurait généré des séquences de signaux pour contrôler des LEDs de puissance. Si les mots "arduino", "PIC" ou "AVR" vous disent quelque chose, ça vous aidera à comprendre l'intérêt du microYASEP actuel. Le YASEP original avait été prévu pour gérer un SystemOnChip multimédia… et peut être utile en robotique.
Le framework est modulaire et pensé dès le début pour supporter d'autres architectures, par contre il faut forker pas mal de fichiers. Evidemment l'assembleur et la documentation devront être refaits et plein d'aspects doivent être adaptés… mais le framework seul ne tient pas debout, j'ai quelques exemples de code de démo mais ils ont juste un intérêt pour les programmeurs JavaScript.
Pour la dernière question, c'est déjà plus ou moins expliqué. Ensuite, j'ai fait ce qui est possible facilement, pratique, portable et dont les gens sont habitués.
et de toute façon, c'est justement en partie à cause de ces pléthores que le YASEP est resté sous le radar si longtemps.
D'un autre côté, c'est aussi une pression et une exigence très forte pour faire des choses de meilleure qualité, accessibles, utiles… Si on compare avec le F-CPU il n'y a pas photo. La rupture était indispensable. Le monde est passé du Minitel 2.0 à l'iPad et la mentalité "utilisateur pour qui on doit tout mâcher" est de plus en plus assumée par tous. C'est pour cela que j'ai préféré prendre 10 ans pour coder avant de montrer, au lieu de blablater sur "le futur".
Donc s'il y a des critiques, je suis intéressé tant que cela permet d'améliorer :-) Toute remarque sera notée !
bon en fait ça n'a rien à voir, il n'y a pas de détection du navigateur mais si JavaScript ne fonctionne pas ou est trop vieux/limité/non standard, le site ne fonctionnera pas.
ça arrive aussi s'il y a un bug interne ;-)
Merci pour le feedback, c'est toujours utile pour améliorer le système !
c'est du javascipt ou du html5 ?
hmmm, comment dire…
"c'est du lard ou du cochon ?" :-D
La vraie réponse c'est que c'est surtout du JavaScript qui devrait passer avec un Firefox3 car il faut que ça puisse tourner sur des ordinateurs peu puissants et/ou des navigateurs pas trop récents ou sophistiqués. Un OLPC XO ou un Raspberry Pi par exemple. Il y a peu de spécificités HTML5 justement pour pouvoir marcher "pas trop mal" partout (sauf sur IE et tablettes mais là, HTML5 n'a rien à voir).
Et aussi la question de la puissance de la plateforme est importante pour le look&feel :
- le "look" est minimaliste. Chaque DIV prend de la place et du temps CPU et pour s'en rendre compte, il suffit de cliquer sur "Ouvrir tout!" avec un P3 à 500MHz. Avec un petit "Arc en ciel" pour alourdir la mule… Lorsqu'une dizaine ou centaine de fenêtres est ouverte, on voit rapidement les limites d'un système.
Ce qui veut dire que toute "décoration" supplémentaire devrait être faite en attributs CSS et ne sera pas mise par défaut.
- le "feel" doit avoir du répondant, l'utilisateur ne doit pas être bloqué par ceci ou cela, donc j'ai des temporisations et je rends la main à l'affichage un peu partout dans l'interface. Rien que déplacer une fenêtre c'est toute une histoire, les interactions au niveau du DOM sont nombreuses et les causes de ralentissement varient d'un navigateur à l'autre, d'un PC à l'autre.
Donc oui le look est spartiate et c'est un choix car je ne pars pas du principe que tout le monde devrait avoir un CoreI7. De plus, n'oublions par que c'est un projet de microprocesseur, utilitaire, pratique, et qui marche, ce n'est pas un projet pour Apple ou une école de design ou d'art. Ensuite si des améliorations sont possibles, je les intégrerai avec grand plaisir après évaluation. Faites péter les patches :-P
Enfin, il y a des personnes qui trouvent que "c'est pas beau", moi ça ne me gène pas, je n'ai jamais prétendu que ce serait E17. C'est sous Affero GPL donc s'ils sont vraiment embêtés, ils peuvent modifier et je suis toujours prêt à aider et faire mieux. Par contre ce qui me gêne c'est que la plupart est incapable de dire pourquoi ça les gêne et comment ça pourrait objectivement être amélioré. D'ici 2013 ou 2014 je ferai un YGWM2 revu et corrigé et j'ai besoin de tous les avis.
[^] # 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é à 3.
En lisant le manuel de l'ISA de RiscV, j'arrêtais pas de me dire "Mais WTF ?" surtout à cause des formats d'instructions super longues qu'il prévoit. D'un autre côté, on voit bien que l'expérience des générations précédentes a été très bénéfique, surtout pour la densité de codage, par exemple la réduction la taille des instructions "classiques" de 32 à 30 bits sans vraiment réduire l'efficacité.
Toutefois, je cherche les réelles innovations. RiscV est très "poli", soigné, mais reste à la base une évolution logique de premiers MIPS, une architecture qui a 30 ans maintenant. J'aurais aimé voir plus de remise en question de certains principes de base, par exemple les mécanismes d'accès à la mémoire (qui sont restés les mêmes depuis le tout début). Les techniques d'écriture ou de lecture de la mémoire, ainsi que les sauts de programme, posent des soucis qui font boule de neige lorsque le cœur grossit, causant des délais de toutes sortes et occupant encore plus de place dans les circuits (prédiction de branchement, logique pour flusher le pipeline…)
F-CPU a exploré une alternative, YASEP va encore plus loin. On est au 21è siècle ou pas ? Ah oui mais on reste encore cloués à des méthodes et outils des années 80-90…
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 5.
Ben oui mais non…
Cela obligerait à s'investir dans une seule architecture propriétaire. Ce n'est pas bien pour la pérennité d'un projet. Pour libérer les utilisateur, il faut leur laisser le choix, donc leur permettre de passer d'une solution à une autre sans trop d'efforts.
Et puis on ne sait jamais ce qu'il pourrait arriver à la famille de puces qu'on a choisi. Il y a quelques années, la startup SiliconBlue avait sorti un FPGA sympa (bien que lent) et s'est faite racheter par Lattice, qui s'est empressé de jeter leur travail par la fenêtre. C'est mignon… Peu après, Actel s'est fait racheter par Microsemi et heureusement ils n'ont pas déconné avec, mais qu'est-ce qui les en aurait empêché ?
Aussi ce n'est pas dans les attributions du projet, qui est de concevoir un CPU et de libérer les utilisateurs. Et puis il faut choisir entre le reverse et la création. Il y a un projet qui a plus ou moins réussi à reverser (partiellement) un FPGA Xilinx mais idéalement, il faudrait (pour tout le monde) un FPGA Libre. Là, c'est un projet d'encore plus grande envergure que F-CPU…
Durs choix.
[^] # Re: Yann Guidon
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 1.
J'ai interviewé l'auteur de GHDL, c'est bien de cela qu'il s'agit ?
Allons bon, voilà maintenant que j'ai l'air inaccessible ? :-D
J'ai un atelier pas loin de la Porte de Pantin, il suffit de me contacter…
Pour les ressources, il y en a plein partout, le dossier VHDL que tu mentionnes est un petit pied à l'étrier.
[^] # Re: Graphique
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 5.
Les cartes graphiques libres pour PC, effectivement, n'ont pas eu beaucoup de chance. Le seul truc à peu près valable a été opengraphics.org qui a fabriqué une belle carte à FPGA. Son générateur de timing programmable est une jolie invention.
Mais aujourd'hui le projet OpenGraphics s'est recentré sur https://github.com/jbush001/NyuziProcessor qui est un cœur de GPU open source.
Au fait il y avait un bruit comme quoi Samsung aimerait bien racheter AMD. De news à ce sujet ?
[^] # Re: Cartes FPGA
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 5.
Pour les cartes low-cost avec un petit FPGA, c'est le YASEP qui convient. Il peut être configuré en 16 ou 32 bits et la densité d'instruction est meilleure, alors que le F-CPU est prévu pour des calculs sur 64 bits. Une telle largeur peut ralentir le CPU s'il faut passer par un bus mémoire plus étroit…
Au moins, en utilisant un environnement de conception unifié (pour configurer le matériel en fonction du code à exécuter, puis pour le simuler), l'architecture du cœur devient moins importante. Il sera bientôt facile d'essayer un morceau de code sur différentes architectures pour voir la taille du code généré, la vitesse d'exécution, les options à activer, les éventuelles extensions à créer… et juste avec des Logiciels Libres (car tout en Affero GPL V3, sauf les synthés proprios).
Ainsi ne se posera plus vraiment la question originale "Ce qui serait vraiment sympa, ce serait que le FCPU puisse tenir sur un XYZ". On code le cœur de l'application voulue puis on essaie avec différents paramètres (taille des registres, taille cache, type de cœur…), on simule, on profile, et on garde ce qui donne le meilleur encombrement de FPGA à performance donnée. Ou ce qui donne la meilleur performance brute. Ou ce qui consomme le moins. Ou…
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 3.
Je suis une nouille, je ne trouve jamais la touche Meta sur mon clavier alors j'utilise nano ;-)
Mais effectivement, GHDL et GTKWave sont vraiment des outils indispensables. Ce que je conçois avec fonctionne souvent dès le premier coup quand je le mets dans un FPGA. Je fais souvent le parallèle entre GCC et GHDL, l'un ayant permis la conception de Linux, l'autre permettant des processeurs libres. L'un comme l'autre changent toute la donne.
[^] # Re: trop tard
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 4.
Je suis d'accord sur le début.
Par contre la conclusion est excessivement simpliste.
[^] # Re: Yann Guidon
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 4.
comme tous les ans ;-)
Je bosse "officiellement" sur http://ygdes.com/WizYasep/ et fin 2015 j'aimerais avoir une 2è génération encore plus puissante. C'est grâce à ces projets que j'aiguise les outils pour le YASEP et F-CPU. J'ai utilisé l'environnement du YASEP pour réaliser un vrai projet pro et je vais continuer de l'améliorer car c'est vraiment pratique !
Mais pour l'instant, ce qui paie mes factures c'est des ptits jobs comme https://www.facebook.com/101308076630787/videos/848924055202515/ et je me bats pour concilier les développements pro et perso. Au moins ça reste dans mon domaine, mais ça me saoule d'avoir plus de réputation dans le domaine des LEDs que des microprocesseurs -_-'
[^] # Re: Cartes FPGA
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 2.
Oui c'est déjà un peu mieux :-)
Un F-CPU est quand même plus à l'aise avec plus de RAM et de bande passante. Par exemple http://m-labs.hk/m1.html commence à devenir confortable.
Actuellement je planche sur l'utilisation de http://emcraft.com/products/255 et un collègue prépare une version plus puissante (jusqu'à 4GB de DDR667). Là, ça commencera à devenir intéressant :-)
[^] # Re: VHDL sous Linux?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 7.
Ah, j'ai dit "sous Linux", j'ai pas parlé de libre (omission stratégique).
On a attendu presque une décennie pour que les outils proprios daignent être portés presque correctement sous nunux…
Donc effectivement, un outil de synthèse-placement-routage libre est un des derniers points critiques pour que ce soit complètement libre. Il est envisageable de générer des .edif avec un synthé open source, un jour, mais tout le reste dépend réellement du fabricant du FPGA, c'est un domaine ultra-propriétaire.
La seule solution est de créer des FPGA "Libres". Mais là cela dépasse largement mes attributions.
En attendant, le "moindre mal" consiste à accepter un petit bout de propriétaire, à condition que 1) on ne peut pas faire autrement 2) on évite au maximum d'utiliser des features trop spécifiques 3) on peut passer à la concurrence sans effort. Tout cela fait qu'il est possible de basculer partie par partie vers du réellement Libre lorsqu'il devient disponible, sans que cela freine l'ensemble du projet.
[^] # Re: Yann Guidon
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 6.
Merci Pierre, j'apprécie beaucoup, et cela fait plus de 10 ans puisque F-CPU a participé à RMLL2002, donc il y a déjà 13 ans…
Concernant les cours/TP, j'y pense depuis longtemps. L'année dernière j'ai eu la possibilité de proposer des conférences pour une école d'ingés infos, mais le boulot m'a rattrapé et je me suis aperçu que je ne pouvais pas faire les deux à la fois, car je suis trop investi, surtout dans les sujets qui me passionnent. Les conférences étant non rémunérées, le choix a malheureusement été vite fait :-( Mais je ne perds pas espoir. Si c'est pour intervenir de temps en temps, et cela ne me prend pas trop de temps à préparer, je suis toujours partant.
# typo
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le retour de F-CPU, le processeur libre. Évalué à 3.
écrire ou dormir, il faut choisir !
"pourquoi pas les faire travailler ensemble"
(désolé, j'avais pourtant relu et rerelu)
[^] # Re: **LA** plateforme
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche DOM et DSP : deux API Javascript intéressantes poussées par Opera. Évalué à 2.
J'arrive après la bataille mais
Il y a bien le protocole HTCPCP
http://fr.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol
mais il manque toujours d'appareils compatibles.
[^] # Re: Qui dit mieux ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche EHSM : Le programme des présentations est disponible !. Évalué à 1.
En anglais ça donne https://twitter.com/d3sre/status/278240664754475008
# Qui dit mieux ?
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche EHSM : Le programme des présentations est disponible !. Évalué à 3.
Et à en croire d'autres, c'est encore mieux que le programme des conférences du CCC :-D
https://twitter.com/honx/status/277882382420414464
[^] # Re: Plutôt d'accord mais
Posté par Yann Guidon (site web personnel) . En réponse au journal Cinema - Skyfall. Évalué à 1.
peut-être que ça va de 0 à 8 et A à G ?
[^] # Re: Le bouchot !!!
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 1.
Hhmmmmm… C'est tentant…
[^] # Re: Le bouchot !!!
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 3.
Effectivement, quand on a la tête dans un truc, et durant un décennie en plus, c'est pas facile de tout expliquer car les référentiels sont parfois trop différents : c'est un peu comme expliquer comment administrer Linux à une personne qui n'a connu que du windows… Mais au moins j'essaie et déjà le fait que des centaines de personnes aient pu essayer et regarder est un grand pas par rapport aux formes "classiques" de projets open hardware. Je ne prendrai comme exemple que OpenCores qui nécessite un enregistrement (pour satisfaire les annonceurs publicitaires) puis l'installation d'outils… Combien vont jusqu'au bout ?
Ensuite c'est vrai que je suis un "technicien" et pas un "designer" et encore moins un expert en esthétique ou ergonomie. Cela permet d'explorer d'autres types d'interactions et je recherche de retours constructifs.
Je suis parti du principe que de nos jours, plus personne ne lit des manuels et préfère cliquer partout, ce qui a influencé la structure du site. Mais aussi, puisque je développe et même utilise cette interface depuis longtemps, je m'y suis habitué… Donc voilà, j'essaie de rapprocher les "référentiels" :-)
Actuellement je prépare la conférence qui contiendra des exemples, que j'inclurai ensuite dans un tutoriel un peu plus parlant. J'espère que cela aidera plus les "curieux" !
[^] # Re: étonnant
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 7.
Bonjour Sygne,
Je n'avais pas vu ça comme ça, plus comme "un truc de geek" :-P
L'unité, c'est la fusion de tout cela et de plus, et même un maximum. Certains éléments n'ont par nature pas de place dans le navigateur (l'interface matérielle surtout) mais tout ce qui peut y entrer y ira. En fait, plein d'initiatives de ce style voient le jour depuis plusieurs années (Chrome OS, Mozilla et son Boot To Gecko, et d'autres encore), et donc pour une fois je me retrouve à l'avant de la vague technologique…
Dans le site, il y a toute la gestion de la documentation, la gestion des E/S fichiers (les entrées sont à refaire mais on peut sauver des fichiers), les outils de programmation en assembleur, et plus tard en graphique avec GNL puis en textuel avec des frontends HLL pour générer du GNL à partir de C/Pascal/FORTH/ce qu'on veut…
Actuellement je travaille sur le simulateur. Il se repose à la fois sur l'assembleur, l'éditeur et d'autres fonctionnalités développées pour les autres fenêtres : plus on ajoute de fonctions, plus le développement des autres pièces est facile et l'ensemble gagne en utilité et puissance. Pour le F-CPU, tout était distinct et donc pénible et désynchronisé, là une petite modif, on sauve et on recharge la page : tout est mis à jour automatiquement. Ah oui, mes 2 outils sont nano et grep :-)
Donc le principe de l'unité c'est de faciliter le développement. Un peu comme Linux et le système GNU, qui ont été conçus pour un développement facile, conçus dans l'optique de leur propre maintenabilité, ce qui favorise le développement des versions et du contenu et forme un système auto-entretenu. L'inventaire de Prévert n'a pas de cohérence apparente ou directe, alors que chaque fenêtre ou module ajouté au site augmente son utilité et utilisabilité, sert à quelque chose et même est nécessaire.
Le principe c'est aussi d'éviter au maximum d'installer des outils externes. C'est l'un des freins majeurs pour l'adoption d'un nouveau système. Installer, adapter, configurer, apprendre à se servir de, puis faire communiquer avec des outils parfois disparates… Si tout est intégré, alors l'installation se résume à avoir un navigateur "correct" (plus un Apache+PHP pour certaines fonctions annexes, et qqs petits trucs que je prépare). Ce qui revient au mantra "utilité et utilisabilité".
Il y a encore 10 ans je voyais JavaScript comme une plaie à éviter à cause de toutes les failles de l'époque et sa lourdeur pour le CPU. Avec les multicores actuels et les optimisations dynamiques, la situation a radicalement changé : notre Bellard national boote Linux dans votre navigateur http://bellard.org/jslinux/ et les jeux prolifèrent (en commençant par http://www.elizium.nu/scripts/lemmings/ ) donc tant qu'on n'a pas besoin de l'ultime performance, pourquoi embêter les gens en les forçant à installer X ou Y, compiler Z et râler à cause de telle ou telle librairie ? Personne ne fait d'effort de nos jours donc l'accessibilité est cruciale pour que les gens commencent à explorer à leur manière : en cliquant.
Ensuite, quelques réponses plus directes :
à maturité, je pense que le microcontrôleur continuera d'être "packagé" avec l'interface. C'est modulaire donc on peut séparer des trucs sans rien casser, comme prendre le contenu du dossier http://yasep.org/VHDL/ pour ne garder que les sources VHDL, ou récupérer YGWM pour faire d'autres sites (Laura utilise déjà YGWM pour coder http://ygllo.com/~llo/MetaFor/code/page_centrale.html ) donc ça dépend de ce dont on a besoin. Mais le tout forme un ensemble cohérent et je ne vois pas d'intérêt à découper.
Je ne suis pas sûr de comprendre ce que "son architecture finalisée" veut dire. Une architecture évolue naturellement, et avec un toolkit comme celui-ci, encore plus vite :-)
Qu'est-ce qu'on programme sur un microcontrôleur ? plein de choses… Par exemple le YASEP a eu un coup de boost lorsque j'ai songé l'utiliser pour un gros projet, où il aurait généré des séquences de signaux pour contrôler des LEDs de puissance. Si les mots "arduino", "PIC" ou "AVR" vous disent quelque chose, ça vous aidera à comprendre l'intérêt du microYASEP actuel. Le YASEP original avait été prévu pour gérer un SystemOnChip multimédia… et peut être utile en robotique.
Le framework est modulaire et pensé dès le début pour supporter d'autres architectures, par contre il faut forker pas mal de fichiers. Evidemment l'assembleur et la documentation devront être refaits et plein d'aspects doivent être adaptés… mais le framework seul ne tient pas debout, j'ai quelques exemples de code de démo mais ils ont juste un intérêt pour les programmeurs JavaScript.
Pour la dernière question, c'est déjà plus ou moins expliqué. Ensuite, j'ai fait ce qui est possible facilement, pratique, portable et dont les gens sont habitués.
[^] # Re: Je ne veux pas casser l'ambiance
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 2.
Je n'avais pas vu ce tag, oops !
Doit-on demander aux modérateurs d'ajouter le tag à la news ?
[^] # Re: Le bouchot !!!
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 2.
au passage, j'étais sous 9WM lorsque j'ai commencé à développer YGWM :-)
[^] # Re: Le bouchot !!!
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 6.
Merci :-)
et de toute façon, c'est justement en partie à cause de ces pléthores que le YASEP est resté sous le radar si longtemps.
D'un autre côté, c'est aussi une pression et une exigence très forte pour faire des choses de meilleure qualité, accessibles, utiles… Si on compare avec le F-CPU il n'y a pas photo. La rupture était indispensable. Le monde est passé du Minitel 2.0 à l'iPad et la mentalité "utilisateur pour qui on doit tout mâcher" est de plus en plus assumée par tous. C'est pour cela que j'ai préféré prendre 10 ans pour coder avant de montrer, au lieu de blablater sur "le futur".
Donc s'il y a des critiques, je suis intéressé tant que cela permet d'améliorer :-) Toute remarque sera notée !
[^] # Re: Oh mon Dieu !
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 3.
Serais-tu par hasard sur BSD ? :-D
bon en fait ça n'a rien à voir, il n'y a pas de détection du navigateur mais si JavaScript ne fonctionne pas ou est trop vieux/limité/non standard, le site ne fonctionnera pas.
ça arrive aussi s'il y a un bug interne ;-)
Merci pour le feedback, c'est toujours utile pour améliorer le système !
[^] # Re: Le bouchot !!!
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 7.
La vraie réponse c'est que c'est surtout du JavaScript qui devrait passer avec un Firefox3 car il faut que ça puisse tourner sur des ordinateurs peu puissants et/ou des navigateurs pas trop récents ou sophistiqués. Un OLPC XO ou un Raspberry Pi par exemple. Il y a peu de spécificités HTML5 justement pour pouvoir marcher "pas trop mal" partout (sauf sur IE et tablettes mais là, HTML5 n'a rien à voir).
Et aussi la question de la puissance de la plateforme est importante pour le look&feel :
- le "look" est minimaliste. Chaque DIV prend de la place et du temps CPU et pour s'en rendre compte, il suffit de cliquer sur "Ouvrir tout!" avec un P3 à 500MHz. Avec un petit "Arc en ciel" pour alourdir la mule… Lorsqu'une dizaine ou centaine de fenêtres est ouverte, on voit rapidement les limites d'un système.
Ce qui veut dire que toute "décoration" supplémentaire devrait être faite en attributs CSS et ne sera pas mise par défaut.
- le "feel" doit avoir du répondant, l'utilisateur ne doit pas être bloqué par ceci ou cela, donc j'ai des temporisations et je rends la main à l'affichage un peu partout dans l'interface. Rien que déplacer une fenêtre c'est toute une histoire, les interactions au niveau du DOM sont nombreuses et les causes de ralentissement varient d'un navigateur à l'autre, d'un PC à l'autre.
Donc oui le look est spartiate et c'est un choix car je ne pars pas du principe que tout le monde devrait avoir un CoreI7. De plus, n'oublions par que c'est un projet de microprocesseur, utilitaire, pratique, et qui marche, ce n'est pas un projet pour Apple ou une école de design ou d'art. Ensuite si des améliorations sont possibles, je les intégrerai avec grand plaisir après évaluation. Faites péter les patches :-P
Pour ceux qui voudraient jouer avec ygwm voici une petite page de démo :
http://yasep.org/gui-js/ygwm-mini.html
Enfin, il y a des personnes qui trouvent que "c'est pas beau", moi ça ne me gène pas, je n'ai jamais prétendu que ce serait E17. C'est sous Affero GPL donc s'ils sont vraiment embêtés, ils peuvent modifier et je suis toujours prêt à aider et faire mieux. Par contre ce qui me gêne c'est que la plupart est incapable de dire pourquoi ça les gêne et comment ça pourrait objectivement être amélioré. D'ici 2013 ou 2014 je ferai un YGWM2 revu et corrigé et j'ai besoin de tous les avis.
# Le bouchot !!!
Posté par Yann Guidon (site web personnel) . En réponse à la dépêche Le microcontrôleur YASEP fait son coming out lors des JM2L 2012. Évalué à 1.
Je ne comprends pas …
363 personnes ont cliqué le lien.
Parmi elles, AUCUNE n'a plopé sur la tribune interne o_O
Bon je vais vous aider un peu, puisque vous êtes timides :
http://yasep.org/#!bouchot
Ah oui tiens, j'aurais dû l'évoquer : parmi les innombrables goodies de l'interface, on peut accéder directement à une fenêtre grâce à un lien externe, comme http://yasep.org/#!ASM/impASM#examples/keywords.yas ou http://yasep.org/#!doc/asm#kw_name
Essayez ça avec Eclipse ou Processing :-P