Et si on pense à RiscV, pouvoir le simuler sur un FPGA peut améliorer l'adoption.
Il ne s'agit pas d'utiliser le FPGA pour simuler le processeur (techniquement ce serait de l'émulation, mais c'est un détail).
Là l'intérêt c'est aussi d'intégrer le FPGA dans le produit final, pour les cas (de plus en plus nombreux) où un circuit intégré sur mesures n'est pas économiquement faisable.
ce n’est pas gravé dans le marbre et que tu peux regraver les portes logiques
Techniquement, la configuration des portes logiques et de leurs interconnexions se fait en chargeant un fichier dans une zone mémoire du FPGA (SRAM le plus souvent). Ce fichier est le bitstream évoqué dans l'article.
Les FPGA ont beaucoup évolué depuis une quinzaine d'années.
Initialement, il n'y avait que des portes logiques (réunies sous la forme de logic cells avec une LUT et un registre), plein de fils pour les interconnecter, et plein de pattes d'entrées/sorties logiques. De plus en plus.
Ensuite, on a rajouté des blocs mémoire (de quelques kilo-octets) et des multiplieurs. Et augmenté le nombre de portes.
À ce moment-là (début des années 2000) on a commencé à pouvoir intégrer des composants logiques aussi complexes qu'un petit microprocesseur dans une matrice FPGA.
Ensuite, on a complexifié les multiplieurs, qui deviennent de vrais DSP configurables et chaînables (addition-multiplication-accumulation) de manière à câbler par exemples des filtres numériques. Et augmenté la taille des mémoires.
Ensuite, on a rajouté des périphériques "en dur" : gestion d'horloge (avec des bouts analogiques), contrôleur mémoire DDR, interfaces série hyper-rapides (pour faire par exemple du PCIe ou du SATA ou du SerialRapidIO). Et encore plus de portes logiques.
Ensuite on a rajouté des processeurs "en dur", un peu de PowerPC mais surtout ARM, avec leur cohorte de périphériques voire GPU. Et la capacité de les coupler finement avec la logique configurable, pour faire des coprocesseurs spécialisés.
Et maintenant, on voit apparaître des co-processeurs massivement parallèles, fortement connectés, pour des applications d'apprentissage ou d'IA de manière générale.
Du coup, il n'y a pas que du FPGA dans les FPGA modernes, ce sont des plate-formes de plus en plus hétérogènes, adaptables à plein de besoins.
On peut faire la même chose qu'avec un microcontrôleur mais beaucoup plus rapidement (signal à 200Mhz et plus).
On n'est vraiment pas dans la même classe de machine. D'ailleurs, la fréquence d'horloge n'est pas le principal facteur : c'est le parallélisme massif du matériel qui donne la puissance de calcul à un FPGA.
Par exemple, tu peux faire travailler un pipeline vidéo à la fréquence pixel (quelques dizaines de MHz en SD, quelques centaines en HD) et faire bien plus de calculs qu'un DSP qui tournerait à plusieurs GHz : les calculs sont étalés physiquement dans la matrice, un peu comme la chaîne d'assemblage d'une usine.
Un autre exemple, les entrées-sorties série très rapides (plusieurs dizaines de Gb/s maintenant) sont fortement dé-sérialisées pour rentrer dans la matrice logique, afin de baisser drastiquement la fréquence et profiter du parallélisme.
L'ordre de grandeur "marketing" des performances maximales des toutes dernières matrices annoncées est en TFLOPS (mille milliards d'opérations flottantes par seconde), centaine de TOPS (calculs entiers), Tb/s (IO et réseau interne).
Un autre aspect intéressant, mais pas très développé, est la capacité à reconfigurer une partie du FPGA pendant qu'il fonctionne. On appelle ca la reconfiguration dynamique partielle, et ca permet par exemple d'adapter les traitements en fonction de l'environnement.
De manière générale, on va pouvoir utiliser des FPGA dans toutes les applications où un processeur standard (CPU, DSP, GPU) n'est pas adapté, mais où la fabrication d'un circuit intégré spécifique (ASIC) n'est pas économiquement rentable. C'est le cas de tous les marchés de niche, et ca progresse avec le coût faramineux des circuits intégrés les plus fins.
Le FPGA sera plus cher à l'unité, mais sans investissement initial, donc adapté aux petites et moyennes séries.
Ca peut être le processeur principal, ou un co-processeur, ou un élément d'une chaîne de traitement plus vaste. Ou un peu tout ca à la fois quand il y a plusieurs fonctions plus ou moins indépendantes dans le système.
Le prototypage d'ASIC est une application historique, toujours présente, mais bien moins massive que dans l'imaginaire collectif.
Là où ça progresse beaucoup, c'est l'utilisation des FPGA comme co-processeurs dans les gros calculateurs de data-centers, comme accélérateurs d'algorithmes d'"intelligence artificielle". Le rachat d'Altera par Intel il y a quelques années est d'ailleurs un signe fort dans cette direction.
L'ambition des créateurs de RISC-V est réellement d'en faire le "Linux du hardware".
C'est probablement le bon moment pour qu'une telle initiative prenne racine. Un aspect important pour l'adoption par l'industrie est que plusieurs implémentations du jeu d'instructions RISC-V sont sous licence BSD, bien plus permissive que la GPL adoptée par le processeur Leon (processeur SPARC utilisé dans le spatial, dont le développement a initialement été financé par l'ESA).
Les terminaux vidéo auxquels tu penses, affectueusement surnommés "minitels", ne sont déjà plus des "vrais" Télétypes : http://en.wikipedia.org/wiki/VT220
C'est pas parce que beaucoup de monde l'utilise que c'est forcément mieux ...
cf. les OS pour desktop, les navigateurs ouaibe, les dispositions de clavier, les cassettes vidéo, etc.
Juste à temps. Je suis passé de fc12 à fc13 hier. :-/
J'étais quand même moins zen avec yum pour une grosse màj comme ca, que sur mon autre bécane qui est passée tout en douceur de lenny (+backports +puredyne) à squeeze. Par exemple, il faut (fallait ?) 3 fois plus d'espace disque avec yum, car il ne fait pas la décompression et le nettoyage au fur et à mesure de l'installation des packages.
Tiens, c'est quoi le truc tout poilu qui vient de passer ?
Par contre, pour les processeurs "en dur", je n'ai aucune idée de la roadmap d'Oracle ...
Pourvu que ce ne soit pas comme HP avec les Alpha et les PA-Risc !
Dans certains cas, des considérations de performance encouragent à ne pas découper en sous-fonctions.
Je suis d'accord que c'est assez spécifique, mais sur des algo de DSP ou de calcul haute performance (HPC), [et non, on ne fait pas/plus que de l'assembleur et du FORTRAN dans ces cas-là !] on peut manipuler beaucoup de boucles imbriquées autour d'un bout de calcul très simple.
Le coût d'un appel de sous-fonction peut alors ne pas être négligeable : empilage des paramètres, branchement + delay slot, et au retour dépilage des valeurs de retour et second branchement + delay slot => ca fait plus d'une dizaine de cycles.
Autour d'un papillon de FFT qui fait moins de 10 cycles, ca peut doubler le temps de calcul !
Par ailleurs on veut souvent laisser le plus de sémantique possible au compilateur, pour qu'il puisse détecter du parallélisme, réordonner les boucles pour optimiser le remplissage des caches, ou bien rendre la fonction inline ... Les trucs à éviter pour que ca marche c'est la linéarisation des tableaux multi-dimensionnels, et l'arithmétique de pointeurs.
Un exemple d'optimisations de ce genre : la librairie Graphite http://gcc.gnu.org/wiki/Graphite , intégrée dans GCC 4.4 http://linuxfr.org/2009/04/21/24809.html
< radote >
La limitation à 80 colonnes, c'était à cause des cartes perforées.
Il n'y a que ceux qui codent encore en FORTRAN 77 (les pauvres) qui subissent encore cette limitation.
< /radote >
La limitation à 80 caractères, ca vient surtout de la taille des cartes perforées ... et donc du FORTRAN (77 et antérieur). Même une vénérable VT100 peut afficher 132 colonnes.
Je suis d'accord qu'il faut des lignes de taille raisonnable, mais j'ai tendance à mettre une limite floue, quelque part vers 120 colonnes, voire plus si le besoin s'en fait sentir.
En tout cas, cumuler des tabulations à 8 espaces et une limitation à 80 caractères par ligne, c'est se tirer une balle dans le pied. Dès qu'on imbrique deux tests et un switch, hop, on est coinçé pour utiliser des noms de variable un peu explicites. Et les retours à la ligne automatiques sont à mon avis un remède bien pire que le mal, en terme de lisibilité.
On peut faire le cas 1 avec des tabulations, et tout restera bien aligné.
Il suffit de mettre une tabulation après la parenthèse ouvrante.
void
ma_fonction( int param1,
int param2,
int param3)
{
}
Cela dit, il m'arrive d'utiliser aussi des espaces, par exemple pour aligner sur plusieurs lignes une condition de test compliquée (avec plein de &&, de || et de parenthèses).
Le second peut notamment être multicœur, et joue sur les plates-bandes de l'Intel Atom. Il sort tout juste, dans les tous derniers OMAP de Texas Instruments, chez Samsung et bientôt dans des FPGA [http://www.electronicsweekly.com/Articles/2010/04/27/48499/x(...)].
Il y a 10 minutes j'aurais suggéré une carte à base de Cortex A8 en attendant la dispo du A9, par exemple la BeagleBoard ou IGEP, mais la PandaBoard semble très intéressante.
Moi aussi j'ai tout de suite pensé à la vidéo de lafkon. On va dire qu'ils ont dû s'en inspirer ...
Par contre j'ai pas vu le logo CreativeCommons sur celle de M$.
Enfin, toute cette histoire me fait plutôt penser à ca :
"First they ignore you, then they ridicule you, then they fight you, then you win."
-- Mahatma Gandhi
Les conditions de brevetabilité sont définies de manière assez précise, c'est l'application de ces conditions par les offices de brevets qui laisse à désirer ...
Effectivement, on ne peut (si tout se passe normalement) breveter que des procédés, pas les idées sous-jacentes. En effet, une idée est une pure oeuvre de l'esprit et n'a pas d'application industrielle directe, seule l'implémentation de l'idée en a. Et il est heureux qu'une autre implémentation de la même idée, qui serait nouvelle, inventive et applicable industriellement soit également récompensée par un avantage concurrentiel provisoire* : ca s'appelle encourager le progrès, et c'est à ca que servent les brevets.
Si on autorise les brevets logiciels, on se retrouve avec une démarche bancale dans tous les cas. Supposons un logiciel proposant une fonctionnalité inédite, astucieuse (même pour un spécialiste) et répondant à une large demande :
- Breveter l'implémentation, ca implique de publier le code source dans le texte du brevet, puisque le logiciel n'est "que" l'expression d'idées dans un langage (informatique). Du coup, il est facile de refaire une implémentation différente, par exemple dans un autre langage, et de contourner ainsi le brevet. On se retrouve tenté d'"obfusquer" le code, ce qui ruine la démarche ...
- Breveter l'implémentation sans la divulguer, ca revient à breveter une boîte noire. C'est contraire à l'idée de capitalisation de la connaissance du système de brevet, qui lutte justement contre le secret, et ca ne permet pas de valider la condition d'inventivité (et parfois celle d'applicabilité). Comment faire valoir un droit sur quelquechose de confidentiel ? Toute ressemblance avec le mécanisme de droit d'auteur et avec l'actualité récente ( http://linuxfr.org/2007/02/28/22134.html ) n'est pas fortuite.
- Breveter l'idée, cela va encore plus loin : même plus besoin de faire une implémentation et de la garder secrète ! Il suffit d'imaginer quelquechose, même si c'est est inapplicable dans l'état de la technique, même si il est trivial, de le décrire en termes suffisamment vagues, et d'attendre. Avec un peu d'habileté rhétorique, ca n'a même pas besoin d'être nouveau. Le premier que se risque à implémenter quelquechose de ressemblant devient une proie juridique facile. C'est un comportement de parasite. Mais le plus grave, c'est que ca verrouille une branche du progrès, un domaine où aucune amélioration n'est possible car la moindre implémentation tombe sous le coup d'un monopole conceptuel.
Allez, un exemple loufoque pour la forme : J'ai rêvé ce matin qu'il serait hyper kewl de faire un logiciel pour prédire l'avenir. C'est nouveau, personne n'a écrit de tel logiciel avant. C'est inventif (enfin, ca se serait si j'avais une idée de comment faire), car ce n'est absolument pas trivial pour l'homme du métier. Et ca aurait sûrement un succès fou si c'était réalisable. Je dépose donc un brevet sur l'idée d'un médium numérique, en brodant 10 pages sur l'idée qui tient dans cet unique paragraphe. Et je vais aussitôt coller des procès à tous les astrologues, devins, marabouts, analystes financiers et météorologues qui ont l'outrecuidance d'utiliser un ordinateur pour exercer leur art divinatoire, au mépris de ma propriété intellectuelle (toute neuve). Et si dans 10 ans un génie trouve un moyen de réellement faire un logiciel pour voir le futur, je pourrai l'empêcher d'exploiter commercialement son implémentation concrète de mon idée abstraite.
Tout ca pour dire qu'un logiciel, c'est couvert par le droit d'auteur, point barre. Tout le reste ne tient pas debout.
* l'étalonnage du terme "provisoire" est également un sujet épineux ...
Je plussoie vigoureusement !
J'ai parfois l'impression que tout le monde ici code des bases de données relationelles en J2EE sur des serveurs virtualisés ...
Mais l'informatique embarquée est un des domaines où notre pingouin préféré a une très forte progression, et bouscule pas mal le marché établi.
Pourtant dans ce domaine, malgré la Loi de Moore, on continue à avoir des besoins de compacité, de faible consommation (donc de faible fréquence, et faible quantité de mémoire) incompatibles avec la "grosse" informatique. Mais avec des besoins de performance quand même importants ! Par exemple, tous les téléphones mobiles modernes sont des systèmes multiprocesseurs, avec 2 à 4 processeurs RISC et DSP ...
On se tourne alors vers des architectures spécifques, comme les DSP, qui présentent un rapport MIPS/Watt très intéressant.
Je rajouterais le chiffre suivant : RAM : 4Go --> 1Mo (code + données)
Vitesse : 2x2.7 GHz --> 720 MHz Consommation : 90W --> 0.9W
Mais indépendamment des questions de ressources plus spartiates en embarqué, il y a un domaine où on ne coupe pas à la gestion des bits un par un : c'est quand on est en contact direct avec le hardware. Pour écrire un bit précis dans un registre (sans faire un ràz des autres bits), et même souvent faire une opération read-test-modify-write qu'on aimerait bien non-interruptible, c'est tout simplement indispensable.
Une méthode pour cela est le "champ de bits", en fait une union entre une structure et la valeur globale du registre. On peut ainsi modifier indépendamment les champs de la structure, et lire/écrire la valeur complète dans le registre. Par contre, si on veut être portable il faut le définir deux fois : une fois en big endian, une fois en little endian.
Exemple approximatif en Little Endian :
typedef bitfield{
typedef union{
unsigned int register;
struct{
int field1 : 1; /* bit 0, LSB */
int field2 : 3; /* bits 1 à 3 */
int field3 : 4; /* bits 4 à 7 */
int nothing : 24; /* bits 8 à 31, MSB */
}bit
}
}
Ensuite, il y a aussi des parties particulières du code, comme les routines d'interruption ou le bootloader, pour lesquelles les contraintes sont telles qu'on échappe rarement à l'écriture de quelques instructions en assembleur.
J'ai acheté ce bouquin à sa sortie, prêté à pas mal d'amis, et je le ressors à l'instant de ma bibliothèque. Je crois bien que c'est suite à cette lecture que j'ai installé ma première distrib' Linux (sur un Mac, ca ressemblait un peu à ca : http://www.linux-france.org/macintosh/JUICE-MA.html)
Concernant la formulation, effectivement le ton est assez clairement à la dénigration, et les arguments techniques ne sont pas toujours très détaillés.
Je pense toutefois qu'il faut se replacer dans le contexte d'il y a 8 ans :
- le grand-public ignore totalement l'existence de systèmes alternatifs
- le monopole de Microsoft commence à devenir vraiment gênant, les premiers procès commencent outre-atlantique
- en France, on est clairement en retard sur Internet (vivent le Minitel et le TO-7) et on bénit M$ de nous sortir de là ...
Le livre est un recueil d'entretiens avec la journaliste Dominique Nora, et par conséquent le texte est issu de l'oral. Les arguments et les exemples sont répartis sur les différents chapitres, les citations qu'on en fait ne sont pas forcément représentatives ... Tout ca explique peut-être la ressemblance avec des posts de DLFP ;-)
Il y a aussi un objectif clairement vulgarisateur et polémique, histoire de faire réagir ce grand-public mené par le bout du nez, sans le faire fuir par des précisions techniques réservées aux initiés. Un pamphlet n'est pas un article de recherche !
Il y a quand même à la fin du bouquin une liste de liens (une demi-douzaine de pages) étayant les prises de position, pour ceux qui veulent creuser la question. (aujourd'hui la plupart de ces liens doivent être morts)
Bref, je pense que pour un pavé jeté dans la mare, c'est un très bon bouquin qu est d'ailleurs très peu obsolète sur le fond.
Par contre, pour une étude technique détaillée et objective des différences entre systèmes d'exploitations, ce n'est pas le meilleur ouvrage ...
Concernant le lecteur embarqué dans la freebox, c'est pas un mplayer modifié ?
Non, c'est fait en hardware. (il y a peut-être toutefois du micocode profondément enfoui)
La puce de la FreeBox V4 ne gère que le MPEG2, c'est pourquoi FreePlayer/VLC doit transcoder le DivX (ou autre) en MPEG-2 avant de l'envoyer à la FreeBoîte.
Concernant la V5, je crois qu'il y a une carte d'encodage/décodage MPEG-4 à bord.
Je disais ca surtout pour montrer le décalage entre le concept initial du brevet et son utilisation actuelle.
L'idée de base du brevet, c'est la publication de l'invention, de manière à faire avancer globalement les sciences et techniques. C'est lutter contre le secret industriel, contre l'oubli. C'est capitaliser le progrès.
C'est finalement très proche de l'idéal de partage de connaissances incarné par Wikipédia.
Evidemment, pour rendre le brevet intéressant pour l'inventeur, il faut lui offrir une contrepartie. On introduit ainsi une exception aux principes capitalistes en autorisant un monopole à durée limitée, censé permettre à l'inventeur de rentabiliser son investissement en R&D, en se faisant une place de choix sur le marché et/ou en concédant des licences.
Le problème, c'est que le "time to market" est devenu bcp plus court que la durée du monopole, surtout dans les domaines électronique et informatique, et que l'on a tendance à breveter n'importe quoi en termes suffisament vagues et le moins détaillés possibles, afin de pouvoir attaquer ou amadouer n'importe quel concurrent gênant.
A la limite, un brevet logiciel serait acceptable si il imposait la publication du code source (intégral et non "obfusqué"), et si il accordait un monopole de courte durée (2 ou 3 ans maxi).
En effet, le système américain (on dépose et ensuite on fait des procès pour voir si c'est valide) fait bosser plus de monde (des avocats surtout).
Le gros souci, c'est l'effet "cépamoicélui" qui en découle.
Normalement, l'office des brevets (USPTO, OEB ...) n'est censé accorder que des brevets valides, après une bonne recherche d'antériorité et des critères de brevetabilité stricts. Un tribunal est donc enclin à donner raison au possesseur d'un brevet, car si l'Office l'a accordé c'est "forcément" que l'invention est valide.
Inversement, les offices de brevets sont rémunérés au nombre de brevets enregistrés. Ils n'ont aucun intérêt à refuser des demandes ! Il est alors facile de se défausser sur les tribunaux, qui jugeront en temps utile de la validité ...
Les deux combinés entraînent une tendace à l'acceptation de n'importe quel brevet, et de sa reconnaissance quasi-automatique par la justice. Les deux institutions se renvoient la responsabilité. Il devient alors presque impossible de résister à une grosse boîte (munie d'une armée d'avocats) qui aurait décider de faire du brevet (abusif) une arme économique.
Et dire que le brevet a été conçu pour éviter que les inventions restent secrètes, et que les inventeurs les emportent dans la tombe ...
Si j'invente un truc, je le publie sur Wikipédia !
Je crois qu'il parle plutôt d'un document ODF suffisamment tarabisco^Wtouffu pour secouer le plug-in en question ... et vérifier sa conformité par rapport à la norme.
[^] # Re: Certes, mais pour quels usages ?
Posté par Jimmy . En réponse au journal 2019, l’année de la libération des FPGA ?. Évalué à 0.
Il ne s'agit pas d'utiliser le FPGA pour simuler le processeur (techniquement ce serait de l'émulation, mais c'est un détail).
Là l'intérêt c'est aussi d'intégrer le FPGA dans le produit final, pour les cas (de plus en plus nombreux) où un circuit intégré sur mesures n'est pas économiquement faisable.
[^] # Re: Qu'est-ce qu'un FPGA ?
Posté par Jimmy . En réponse au journal 2019, l’année de la libération des FPGA ?. Évalué à 9. Dernière modification le 16 janvier 2019 à 19:24.
Techniquement, la configuration des portes logiques et de leurs interconnexions se fait en chargeant un fichier dans une zone mémoire du FPGA (SRAM le plus souvent). Ce fichier est le bitstream évoqué dans l'article.
Les FPGA ont beaucoup évolué depuis une quinzaine d'années.
Initialement, il n'y avait que des portes logiques (réunies sous la forme de logic cells avec une LUT et un registre), plein de fils pour les interconnecter, et plein de pattes d'entrées/sorties logiques. De plus en plus.
Ensuite, on a rajouté des blocs mémoire (de quelques kilo-octets) et des multiplieurs. Et augmenté le nombre de portes.
À ce moment-là (début des années 2000) on a commencé à pouvoir intégrer des composants logiques aussi complexes qu'un petit microprocesseur dans une matrice FPGA.
Ensuite, on a complexifié les multiplieurs, qui deviennent de vrais DSP configurables et chaînables (addition-multiplication-accumulation) de manière à câbler par exemples des filtres numériques. Et augmenté la taille des mémoires.
Ensuite, on a rajouté des périphériques "en dur" : gestion d'horloge (avec des bouts analogiques), contrôleur mémoire DDR, interfaces série hyper-rapides (pour faire par exemple du PCIe ou du SATA ou du SerialRapidIO). Et encore plus de portes logiques.
Ensuite on a rajouté des processeurs "en dur", un peu de PowerPC mais surtout ARM, avec leur cohorte de périphériques voire GPU. Et la capacité de les coupler finement avec la logique configurable, pour faire des coprocesseurs spécialisés.
Et maintenant, on voit apparaître des co-processeurs massivement parallèles, fortement connectés, pour des applications d'apprentissage ou d'IA de manière générale.
Du coup, il n'y a pas que du FPGA dans les FPGA modernes, ce sont des plate-formes de plus en plus hétérogènes, adaptables à plein de besoins.
On n'est vraiment pas dans la même classe de machine. D'ailleurs, la fréquence d'horloge n'est pas le principal facteur : c'est le parallélisme massif du matériel qui donne la puissance de calcul à un FPGA.
Par exemple, tu peux faire travailler un pipeline vidéo à la fréquence pixel (quelques dizaines de MHz en SD, quelques centaines en HD) et faire bien plus de calculs qu'un DSP qui tournerait à plusieurs GHz : les calculs sont étalés physiquement dans la matrice, un peu comme la chaîne d'assemblage d'une usine.
Un autre exemple, les entrées-sorties série très rapides (plusieurs dizaines de Gb/s maintenant) sont fortement dé-sérialisées pour rentrer dans la matrice logique, afin de baisser drastiquement la fréquence et profiter du parallélisme.
L'ordre de grandeur "marketing" des performances maximales des toutes dernières matrices annoncées est en TFLOPS (mille milliards d'opérations flottantes par seconde), centaine de TOPS (calculs entiers), Tb/s (IO et réseau interne).
Un autre aspect intéressant, mais pas très développé, est la capacité à reconfigurer une partie du FPGA pendant qu'il fonctionne. On appelle ca la reconfiguration dynamique partielle, et ca permet par exemple d'adapter les traitements en fonction de l'environnement.
[^] # Re: Certes, mais pour quels usages ?
Posté par Jimmy . En réponse au journal 2019, l’année de la libération des FPGA ?. Évalué à 7. Dernière modification le 16 janvier 2019 à 18:35.
De manière générale, on va pouvoir utiliser des FPGA dans toutes les applications où un processeur standard (CPU, DSP, GPU) n'est pas adapté, mais où la fabrication d'un circuit intégré spécifique (ASIC) n'est pas économiquement rentable. C'est le cas de tous les marchés de niche, et ca progresse avec le coût faramineux des circuits intégrés les plus fins.
Le FPGA sera plus cher à l'unité, mais sans investissement initial, donc adapté aux petites et moyennes séries.
C'est une technologie très présente dans le domaine des systèmes embarqués, des infrastructures réseau (routage de paquets), du traitement de signal en temps-réel (audio, radar, télécom, sonar, vidéo …)
Deux exemples récents en audio :
https://fr.antelopeaudio.com/hardware-based-fpga-effects/
https://fr.audiofanzine.com/synthetiseur-hybride-analogique-numerique/novation/peak/editorial/tests/am-stram-gram.html
Ca peut être le processeur principal, ou un co-processeur, ou un élément d'une chaîne de traitement plus vaste. Ou un peu tout ca à la fois quand il y a plusieurs fonctions plus ou moins indépendantes dans le système.
Le prototypage d'ASIC est une application historique, toujours présente, mais bien moins massive que dans l'imaginaire collectif.
Là où ça progresse beaucoup, c'est l'utilisation des FPGA comme co-processeurs dans les gros calculateurs de data-centers, comme accélérateurs d'algorithmes d'"intelligence artificielle". Le rachat d'Altera par Intel il y a quelques années est d'ailleurs un signe fort dans cette direction.
[^] # Re: Lien eBook
Posté par Jimmy . En réponse au journal Thales rejoint la fondation RISC-V pour participer à la sécurisation des uProcesseurs open source. Évalué à 2.
C'est tout frais : https://github.com/Thales-RISC-V
[^] # Re: RISC-V
Posté par Jimmy . En réponse au journal Thales rejoint la fondation RISC-V pour participer à la sécurisation des uProcesseurs open source. Évalué à 4.
L'ambition des créateurs de RISC-V est réellement d'en faire le "Linux du hardware".
C'est probablement le bon moment pour qu'une telle initiative prenne racine. Un aspect important pour l'adoption par l'industrie est que plusieurs implémentations du jeu d'instructions RISC-V sont sous licence BSD, bien plus permissive que la GPL adoptée par le processeur Leon (processeur SPARC utilisé dans le spatial, dont le développement a initialement été financé par l'ESA).
[^] # Re: Utiliser les tty
Posté par Jimmy . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 1.
D'autant plus qu'un vrai TTY n'avait pas d'écran ...
http://en.wikipedia.org/wiki/Teletypewriter
Les terminaux vidéo auxquels tu penses, affectueusement surnommés "minitels", ne sont déjà plus des "vrais" Télétypes : http://en.wikipedia.org/wiki/VT220
[^] # Re: Découverte
Posté par Jimmy . En réponse à la dépêche Red Hat lance RHEL 6. Évalué à 2.
cf. les OS pour desktop, les navigateurs ouaibe, les dispositions de clavier, les cassettes vidéo, etc.
[^] # Re: Bravo
Posté par Jimmy . En réponse à la dépêche Testez la nouvelle version de LinuxFr.org. Évalué à 7.
[^] # Re: Youpi !!!
Posté par Jimmy . En réponse à la dépêche Sortie de Fedora 14. Évalué à 10.
J'étais quand même moins zen avec yum pour une grosse màj comme ca, que sur mon autre bécane qui est passée tout en douceur de lenny (+backports +puredyne) à squeeze. Par exemple, il faut (fallait ?) 3 fois plus d'espace disque avec yum, car il ne fait pas la décompression et le nettoyage au fur et à mesure de l'installation des packages.
Tiens, c'est quoi le truc tout poilu qui vient de passer ?
[^] # Re: Sparc
Posté par Jimmy . En réponse à la dépêche Le rachat de Sun par Oracle : 18 mois plus tard la méfiance s'installe. Évalué à 5.
En ce qui concerne le design, il est libre (GPL) : http://www.opensparc.net/
J'ai même réussi à synthétiser un cœur du T1 sur un FPGA.
Par contre, pour les processeurs "en dur", je n'ai aucune idée de la roadmap d'Oracle ...
Pourvu que ce ne soit pas comme HP avec les Alpha et les PA-Risc !
[^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne
Posté par Jimmy . En réponse au sondage La taille de l'indentation de mon code source (tab ou espace). Évalué à 2.
Je suis d'accord que c'est assez spécifique, mais sur des algo de DSP ou de calcul haute performance (HPC), [et non, on ne fait pas/plus que de l'assembleur et du FORTRAN dans ces cas-là !] on peut manipuler beaucoup de boucles imbriquées autour d'un bout de calcul très simple.
Le coût d'un appel de sous-fonction peut alors ne pas être négligeable : empilage des paramètres, branchement + delay slot, et au retour dépilage des valeurs de retour et second branchement + delay slot => ca fait plus d'une dizaine de cycles.
Autour d'un papillon de FFT qui fait moins de 10 cycles, ca peut doubler le temps de calcul !
Par ailleurs on veut souvent laisser le plus de sémantique possible au compilateur, pour qu'il puisse détecter du parallélisme, réordonner les boucles pour optimiser le remplissage des caches, ou bien rendre la fonction inline ... Les trucs à éviter pour que ca marche c'est la linéarisation des tableaux multi-dimensionnels, et l'arithmétique de pointeurs.
Un exemple d'optimisations de ce genre : la librairie Graphite http://gcc.gnu.org/wiki/Graphite , intégrée dans GCC 4.4 http://linuxfr.org/2009/04/21/24809.html
< radote >
La limitation à 80 colonnes, c'était à cause des cartes perforées.
Il n'y a que ceux qui codent encore en FORTRAN 77 (les pauvres) qui subissent encore cette limitation.
< /radote >
[^] # Re: Indentation par l'espace
Posté par Jimmy . En réponse au sondage J'indente mon code source avec. Évalué à 7.
Je suis d'accord qu'il faut des lignes de taille raisonnable, mais j'ai tendance à mettre une limite floue, quelque part vers 120 colonnes, voire plus si le besoin s'en fait sentir.
En tout cas, cumuler des tabulations à 8 espaces et une limitation à 80 caractères par ligne, c'est se tirer une balle dans le pied. Dès qu'on imbrique deux tests et un switch, hop, on est coinçé pour utiliser des noms de variable un peu explicites. Et les retours à la ligne automatiques sont à mon avis un remède bien pire que le mal, en terme de lisibilité.
[^] # Re: Le FALSE, il n'y a que ça de vrai !
Posté par Jimmy . En réponse au sondage J'indente mon code source avec. Évalué à 2.
Le Whitespace, dérivé du Brainf*ck, qui est lui-même un descendant du FALSE.
http://99-bottles-of-beer.net/language-whitespace-154.html
[^] # Re: Et les elastic tabstops ?
Posté par Jimmy . En réponse au sondage J'indente mon code source avec. Évalué à 3.
Il suffit de mettre une tabulation après la parenthèse ouvrante.
voidma_fonction( int param1,
int param2,
int param3)
{
}
Cela dit, il m'arrive d'utiliser aussi des espaces, par exemple pour aligner sur plusieurs lignes une condition de test compliquée (avec plein de &&, de || et de parenthèses).
[^] # Re: au pluriel, avec un s
Posté par Jimmy . En réponse à la dépêche Sortie du projet OpenBricks: un framework pour Linux embarqué.. Évalué à 4.
http://en.wikipedia.org/wiki/ARM9
http://en.wikipedia.org/wiki/Cortex_A9
Le second peut notamment être multicœur, et joue sur les plates-bandes de l'Intel Atom. Il sort tout juste, dans les tous derniers OMAP de Texas Instruments, chez Samsung et bientôt dans des FPGA [http://www.electronicsweekly.com/Articles/2010/04/27/48499/x(...)].
Il y a 10 minutes j'aurais suggéré une carte à base de Cortex A8 en attendant la dispo du A9, par exemple la BeagleBoard ou IGEP, mais la PandaBoard semble très intéressante.
[^] # Re: Acide ?
Posté par Jimmy . En réponse au journal FUD Microsoft. Évalué à 1.
Par contre j'ai pas vu le logo CreativeCommons sur celle de M$.
Enfin, toute cette histoire me fait plutôt penser à ca :
"First they ignore you, then they ridicule you, then they fight you, then you win."
-- Mahatma Gandhi
[^] # Re: Insécurité juridique liée aux brevets logiciels
Posté par Jimmy . En réponse à la dépêche Insécurité juridique : On a le droit d'exiger du logiciel libre dans les marchés publics. Évalué à 4.
On liste généralement 3 conditions :
- nouveauté
- inventivité
- application industrielle
(plus de détails ici : http://fr.wikipedia.org/wiki/Brevet#Droit )
Effectivement, on ne peut (si tout se passe normalement) breveter que des procédés, pas les idées sous-jacentes. En effet, une idée est une pure oeuvre de l'esprit et n'a pas d'application industrielle directe, seule l'implémentation de l'idée en a. Et il est heureux qu'une autre implémentation de la même idée, qui serait nouvelle, inventive et applicable industriellement soit également récompensée par un avantage concurrentiel provisoire* : ca s'appelle encourager le progrès, et c'est à ca que servent les brevets.
Si on autorise les brevets logiciels, on se retrouve avec une démarche bancale dans tous les cas. Supposons un logiciel proposant une fonctionnalité inédite, astucieuse (même pour un spécialiste) et répondant à une large demande :
- Breveter l'implémentation, ca implique de publier le code source dans le texte du brevet, puisque le logiciel n'est "que" l'expression d'idées dans un langage (informatique). Du coup, il est facile de refaire une implémentation différente, par exemple dans un autre langage, et de contourner ainsi le brevet. On se retrouve tenté d'"obfusquer" le code, ce qui ruine la démarche ...
- Breveter l'implémentation sans la divulguer, ca revient à breveter une boîte noire. C'est contraire à l'idée de capitalisation de la connaissance du système de brevet, qui lutte justement contre le secret, et ca ne permet pas de valider la condition d'inventivité (et parfois celle d'applicabilité). Comment faire valoir un droit sur quelquechose de confidentiel ? Toute ressemblance avec le mécanisme de droit d'auteur et avec l'actualité récente ( http://linuxfr.org/2007/02/28/22134.html ) n'est pas fortuite.
- Breveter l'idée, cela va encore plus loin : même plus besoin de faire une implémentation et de la garder secrète ! Il suffit d'imaginer quelquechose, même si c'est est inapplicable dans l'état de la technique, même si il est trivial, de le décrire en termes suffisamment vagues, et d'attendre. Avec un peu d'habileté rhétorique, ca n'a même pas besoin d'être nouveau. Le premier que se risque à implémenter quelquechose de ressemblant devient une proie juridique facile. C'est un comportement de parasite. Mais le plus grave, c'est que ca verrouille une branche du progrès, un domaine où aucune amélioration n'est possible car la moindre implémentation tombe sous le coup d'un monopole conceptuel.
Allez, un exemple loufoque pour la forme : J'ai rêvé ce matin qu'il serait hyper kewl de faire un logiciel pour prédire l'avenir. C'est nouveau, personne n'a écrit de tel logiciel avant. C'est inventif (enfin, ca se serait si j'avais une idée de comment faire), car ce n'est absolument pas trivial pour l'homme du métier. Et ca aurait sûrement un succès fou si c'était réalisable. Je dépose donc un brevet sur l'idée d'un médium numérique, en brodant 10 pages sur l'idée qui tient dans cet unique paragraphe. Et je vais aussitôt coller des procès à tous les astrologues, devins, marabouts, analystes financiers et météorologues qui ont l'outrecuidance d'utiliser un ordinateur pour exercer leur art divinatoire, au mépris de ma propriété intellectuelle (toute neuve). Et si dans 10 ans un génie trouve un moyen de réellement faire un logiciel pour voir le futur, je pourrai l'empêcher d'exploiter commercialement son implémentation concrète de mon idée abstraite.
Tout ca pour dire qu'un logiciel, c'est couvert par le droit d'auteur, point barre. Tout le reste ne tient pas debout.
* l'étalonnage du terme "provisoire" est également un sujet épineux ...
[^] # Re: Bravo
Posté par Jimmy . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 5.
J'ai parfois l'impression que tout le monde ici code des bases de données relationelles en J2EE sur des serveurs virtualisés ...
Mais l'informatique embarquée est un des domaines où notre pingouin préféré a une très forte progression, et bouscule pas mal le marché établi.
Pourtant dans ce domaine, malgré la Loi de Moore, on continue à avoir des besoins de compacité, de faible consommation (donc de faible fréquence, et faible quantité de mémoire) incompatibles avec la "grosse" informatique. Mais avec des besoins de performance quand même importants ! Par exemple, tous les téléphones mobiles modernes sont des systèmes multiprocesseurs, avec 2 à 4 processeurs RISC et DSP ...
On se tourne alors vers des architectures spécifques, comme les DSP, qui présentent un rapport MIPS/Watt très intéressant.
Je rajouterais le chiffre suivant :
RAM : 4Go --> 1Mo (code + données)
Vitesse : 2x2.7 GHz --> 720 MHz
Consommation : 90W --> 0.9W
Mais indépendamment des questions de ressources plus spartiates en embarqué, il y a un domaine où on ne coupe pas à la gestion des bits un par un : c'est quand on est en contact direct avec le hardware. Pour écrire un bit précis dans un registre (sans faire un ràz des autres bits), et même souvent faire une opération read-test-modify-write qu'on aimerait bien non-interruptible, c'est tout simplement indispensable.
Une méthode pour cela est le "champ de bits", en fait une union entre une structure et la valeur globale du registre. On peut ainsi modifier indépendamment les champs de la structure, et lire/écrire la valeur complète dans le registre. Par contre, si on veut être portable il faut le définir deux fois : une fois en big endian, une fois en little endian.
Exemple approximatif en Little Endian :
Ensuite, il y a aussi des parties particulières du code, comme les routines d'interruption ou le bootloader, pour lesquelles les contraintes sont telles qu'on échappe rarement à l'écriture de quelques instructions en assembleur.
[^] # Re: Motif(s) du refus de rééditer l'ouvrage ?
Posté par Jimmy . En réponse à la dépêche Le Hold-up planétaire dans le cyberespace. Évalué à 5.
Concernant la formulation, effectivement le ton est assez clairement à la dénigration, et les arguments techniques ne sont pas toujours très détaillés.
Je pense toutefois qu'il faut se replacer dans le contexte d'il y a 8 ans :
- le grand-public ignore totalement l'existence de systèmes alternatifs
- le monopole de Microsoft commence à devenir vraiment gênant, les premiers procès commencent outre-atlantique
- en France, on est clairement en retard sur Internet (vivent le Minitel et le TO-7) et on bénit M$ de nous sortir de là ...
Le livre est un recueil d'entretiens avec la journaliste Dominique Nora, et par conséquent le texte est issu de l'oral. Les arguments et les exemples sont répartis sur les différents chapitres, les citations qu'on en fait ne sont pas forcément représentatives ... Tout ca explique peut-être la ressemblance avec des posts de DLFP ;-)
Il y a aussi un objectif clairement vulgarisateur et polémique, histoire de faire réagir ce grand-public mené par le bout du nez, sans le faire fuir par des précisions techniques réservées aux initiés. Un pamphlet n'est pas un article de recherche !
Il y a quand même à la fin du bouquin une liste de liens (une demi-douzaine de pages) étayant les prises de position, pour ceux qui veulent creuser la question. (aujourd'hui la plupart de ces liens doivent être morts)
Bref, je pense que pour un pavé jeté dans la mare, c'est un très bon bouquin qu est d'ailleurs très peu obsolète sur le fond.
Par contre, pour une étude technique détaillée et objective des différences entre systèmes d'exploitations, ce n'est pas le meilleur ouvrage ...
[^] # Re: Un parallèle amusant !
Posté par Jimmy . En réponse à la dépêche Le conseil constitutionnel aggrave encore DADVSI. Évalué à 3.
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://web.lemuria.org/DeCSS/
[^] # Re: Un parallèle amusant !
Posté par Jimmy . En réponse à la dépêche Le conseil constitutionnel aggrave encore DADVSI. Évalué à 0.
Non, c'est fait en hardware. (il y a peut-être toutefois du micocode profondément enfoui)
La puce de la FreeBox V4 ne gère que le MPEG2, c'est pourquoi FreePlayer/VLC doit transcoder le DivX (ou autre) en MPEG-2 avant de l'envoyer à la FreeBoîte.
Concernant la V5, je crois qu'il y a une carte d'encodage/décodage MPEG-4 à bord.
[^] # Re: le P2P c'est quoi?
Posté par Jimmy . En réponse à la dépêche Le conseil constitutionnel aggrave encore DADVSI. Évalué à 0.
La Poste me semble être un coupable tout trouvé.
Et la bande passante d'un DVD-DL en Chronoposte n'est pas négligeable !
[^] # Re: Poursuivre l'administration qui valide les brevets ?
Posté par Jimmy . En réponse à la dépêche Red Hat en justice pour violation de brevets logiciels. Évalué à 2.
L'idée de base du brevet, c'est la publication de l'invention, de manière à faire avancer globalement les sciences et techniques. C'est lutter contre le secret industriel, contre l'oubli. C'est capitaliser le progrès.
C'est finalement très proche de l'idéal de partage de connaissances incarné par Wikipédia.
Evidemment, pour rendre le brevet intéressant pour l'inventeur, il faut lui offrir une contrepartie. On introduit ainsi une exception aux principes capitalistes en autorisant un monopole à durée limitée, censé permettre à l'inventeur de rentabiliser son investissement en R&D, en se faisant une place de choix sur le marché et/ou en concédant des licences.
Le problème, c'est que le "time to market" est devenu bcp plus court que la durée du monopole, surtout dans les domaines électronique et informatique, et que l'on a tendance à breveter n'importe quoi en termes suffisament vagues et le moins détaillés possibles, afin de pouvoir attaquer ou amadouer n'importe quel concurrent gênant.
A la limite, un brevet logiciel serait acceptable si il imposait la publication du code source (intégral et non "obfusqué"), et si il accordait un monopole de courte durée (2 ou 3 ans maxi).
[^] # Re: Poursuivre l'administration qui valide les brevets ?
Posté par Jimmy . En réponse à la dépêche Red Hat en justice pour violation de brevets logiciels. Évalué à 7.
Le gros souci, c'est l'effet "cépamoicélui" qui en découle.
Normalement, l'office des brevets (USPTO, OEB ...) n'est censé accorder que des brevets valides, après une bonne recherche d'antériorité et des critères de brevetabilité stricts. Un tribunal est donc enclin à donner raison au possesseur d'un brevet, car si l'Office l'a accordé c'est "forcément" que l'invention est valide.
Inversement, les offices de brevets sont rémunérés au nombre de brevets enregistrés. Ils n'ont aucun intérêt à refuser des demandes ! Il est alors facile de se défausser sur les tribunaux, qui jugeront en temps utile de la validité ...
Les deux combinés entraînent une tendace à l'acceptation de n'importe quel brevet, et de sa reconnaissance quasi-automatique par la justice. Les deux institutions se renvoient la responsabilité. Il devient alors presque impossible de résister à une grosse boîte (munie d'une armée d'avocats) qui aurait décider de faire du brevet (abusif) une arme économique.
Et dire que le brevet a été conçu pour éviter que les inventions restent secrètes, et que les inventeurs les emportent dans la tombe ...
Si j'invente un truc, je le publie sur Wikipédia !
[^] # Re: [troll inside]Un validateur pour openDocument?
Posté par Jimmy . En réponse à la dépêche Microsoft se met à l'Open Document. Évalué à 3.
Un peu comme Acid2 pour les navigateurs http://www.webstandards.org/action/acid2/