ymorin a écrit 498 commentaires

Déjà, je vois plusieurs désavantages à ce meuble ^ W ^ W cette TV ^ W ^ W ce truc…

1. J´aime pô. OK, ce n´est pas très argumenté. ;-)

2. Le peu que je suis devant la télé, c´est déjà en utilisation conjointe avec un media-center : DVD, CD, cartes mémoire, streaming depuis mon serveur, etc … J´ai tout monté moi-même, et pourtant je ne vois vraiment aucun câble (même ceux des canaux arrière, ils passent sous la dalle ; donc, OK, je les vois dans le sous-sol)

3. Les télés connectées, c´est un piège. On est pieds-et-poings liés avec un fournisseur. Si celui-ci décide de changer ses conditions d´accès, ou disparaît, il faut changer de télé, ou racheter un … media-center, avec le risque de ne pas pouvoir le brancher correctement, voir pas du tout. Pff …

4. Les télés connectées, c´est Farenheit 451 qui entre dans la maison. Instrumentalisation à outrance avec pour but la collecte d´infos (combien zappent les pubs, le journal, regardent telle chaîne, à quelle heure, combien de temps … ) ; mais aussi, avec une caméra, combien sont devant la télé, quels âges, à quelle heure, ce qu´ils font … IKEA, avec la récente affaire de non-respect de la vie privée de ses salariés, ne donne guère confiance de ce côté-là…

Pour moi, la télé doit rester un terminal neutre, un bête écran. La ou les boîtes qui amènent l´intelligence peuvent aller dans le meuble dessous, être accrochées derrière (support VESA), voire posées à côté si elle sont design ; un joli passe-câbles peut être utilisé sur le mur, etc …

Hop,
Moi.

netstat -pnW --tcp

… vas afficher la liste des connexions TCP, et pour chaque connexion, les adresses locale et distante, le port utilisé, et le programme concerné.

netsat -pnW --udp

… pareil pour l'UDP.

Hop,
Moi.

Dans l´ensemble, tu n´as pas tort. Mais tu as dû loupé (je pense) ces deux petits passages (oui, les mots ont de l´importance ;-) ) :

De manière généralement admise […] la compilation consiste à traduire un programme […] en instructions interprétables par le CPU
Traduire d´un langage à un autre […] on parle de trans-compilation.

… dans lesquels je précisait quand même le cadre ;-)

prendre un programme écrit en Go, et émettre du code C
compiler (par exemple) d'un langage assembleur x86 vers un langage assembleur Itanium

Ce n´est pas techniquement impossible (et quand même sacrément tordu dans le deuxième cas ;-) ), mais ce n'est pas ce que de manière générale on appelle de la compilation. Dans ces cas, on parle plutôt de trans-compilation (j´ai même vu une fois tradu-compilation).

Attention, aussi : l´assembleur est un langage ! Ce n´est pas la même chose que le code binaire qui s´exécute sur le CPU.

En détails, ça donne :
[…]

Globalement, oui. À ceci près que l'IR de haut niveau peut déjà subir des transformation avant de passer dans le middle-end :

[SRC] -> FE -> [HLIR] -> OPTIM -> [HLIR] -> ME/OPTIM -> [LLIR] -> BE -> [ASM] -> ASM/OPTIM -> [OBJ]

Données au format [X] :

• SRC = Code source
• HLIR = High-Level IR
• LLIR = Low-Level IR
• ASM = Code assembleur
• OBJ = Code objet (aka binaire)

Actions [X] :

• FE = Frontend
• OPTIM = Optimisers
• ME = Middle-end
• BE = Backend

Par exemple, OCaml

Ou Go, plus récemment ; et des tas d'autres : Eiffel, Pascal… Et j'ai aussi écrit un trans-compilateur pour traduire des automates à états vers du C.

Mais il se fait tard, et l´on pourrait dire que, la fatigue aidant, nous pinaillions sur les mots… Moins de 24h à attendre pour reprendre la discussion ! ;-p

Hop,
Moi.

dans ce cas, il ne s'agit pas de simplement passer le bon paramètre au compilateur ?

Dans la théorie, cela pourrait être le cas. On aurait alors (en gros) :

• un frontal qui interprète le langage (eg. le C) et émet une représentation intermédiaire (IR, intermediate representation) du programme (pour gcc, c´est du GIMPLE (in-memory, pas de on-disk), pour llvm, c´est du bitcode (on-disk, pas de nom pour in-memory)
• un ou plusieurs optimiseurs qui modifient la structure de l´IR (et donc émettent aussi de l´IR)
• un backend qui interprète l'IR et émet du code assembleur
• l´éditeur de liens (linker) qui émet du code binaire

En fonction des flags passés au compilateur (ou en fonction de son nom), le compilateur peut alors choisir quel backend et éditeur de liens utiliser.

C´est globalement la structure utilisée par LLVM, mais pas pour gcc. Pour gcc, le frontal, les optimiseurs et le backend sont dans le même binaire (en gros). Si tu veux rajouter un frontal ou un backend, il faut recompiler tout gcc (tsss…).

De plus, pour LLVM, les optimiseurs peuvent être des programmes ou librairies à part. Pour gcc, ce ne peut être que des librairies, et c´est plus dur à utiliser, vu que GIMPLE est peu documenté (à ma connaissance). Pour LLVM, bitcode est très bien documenté, ce qui rend l´écriture d´optimiseurs plus facile.

Mais en gros, dans le monde 'gcc', vu que le backend est intégré aux frontaux, ajouter une cible ou un langage implique de recompiler tout gcc…

Hop,
Moi.

quelle est la difficulté à compiler pour une plateforme X sur une plateforme Y ?

Rien de compliqué. Il faut juste avoir une chaîne de compilation croisée. Et c'est là le hic : générer ou obtenir une telle chaîne de compilation n'est pas trivial…

Juste pour info : How is a toolchain constructed?

il s'agit "juste" de traduire d'un langage à un autre

De manière généralement admise, la compilation consiste à traduire un programme écrit dans un langage de haut niveau (ie. compréhensible par humain, comme le C), en instructions interprétables par le CPU (ie. une suite d'octets, du 'code binaire').

Chaque architecture (ARM, x86, MIPS…) possède son propre jeu d'instructions, non compatibles entre eux. Donc il faut une chaîne de compilation spécifique pour chaque architecture (voire, comme expliqué plus haut, pour chaque combinaison de variante de CPU, de flags, de libc, etc…).

Traduire d'un langage à un autre (eg. prendre un programme écrit en Go, et émttre du code C) n'est généralement pas considéré comme de la compilation. Dans ce cas on parle de trans-compilation. (et pas de cross-compilation).

NB: le code assembleur est déjà un langage de programmation, de bas niveau, mais doit tout de même être 'compilé' (dans ce cas particulier, on dit 'assemblé') pour générer du code binaire.

C´est pas moi qui ai commencé à en parler, alors je l´ai replacé un peu plus haut ! ;-]

Mais bon, content de voir que des gens le recommande ! :-)

Hop,
Moi.

le projet emdebian.org

Je dis rien, on va attendre vendredi… ;-]

MOST PEOPLE SHOULDN'T BE BUILDING THEIR OWN CROSS-TOOLCHAIN - THEY SHOULD JUST INSTALL A PRE-BUILT ONE LIKE ANY OTHER PACKAGE.

Bon tant pis : Bwaahhaaa !
Non, sans déc´, ils y croient toujours ?

Bon sinon, compiler sa propre toolchain, c´est pas si compliqué : crosstool-NG est là pour ça (et pas plus ; ni moins, d´ailleurs). Et crossdev (que je ne connais pas) de Gentoo. Et buildroot, OpenEmbedded, openWRT, OpenBricks pour construire de systèmes complets…

Hop,
Moi.

Il y a une différence entre "tourner sur ARM" et "cross-compiler pour ARM".

La plupart des grandes distros, y compris Fedora, Debian (et donc Ubuntu), openSUSE, etc.. ne sont pas cross-compilées, mais sont compilées nativement. Le projet Debian, par exemple, possède un cluster de machine ARM (je sais plus trop laquelle, exactement), sur lequel la distrib est compilée nativement pour ARM.

Idem pour les autres architectures : PPC, MIPS, x86…

Hop,
Moi.

i486 pour […] Debian

Heu, sur Squeeze, c´est i586. IIRC, i486 ne supporte NPTL, et glibc/eglibc sont NPTL depuis longtemps (les LinuxThreads sont morts depuis au moins 5 ans, déjà qu´ils étaient pas en grande forme avant ! ;-) )…

Hop,
Moi.

quand j'installe ma distrib, déjà elle tourne sur n'importe quelle variation (du moins beaucoup) de ix86 sans problème

Le plus petit dénominateur commun… ;-) Pour ix86, c'est souvent i586 de nos jours, notamment car NPTL ne supporte pas i386 (ni i486 IIRC).

Et comme tu dis, ce n´est pas optimisé. Exit l´accélération SSE pour le calcul de hash ; exit l´accélération SSE3 pour le calcul 3DES… (exemples ! )

Certains programmes ont cependant une détection à l´exécution pour utiliser certaines routines ou d'autres en fonction du CPU (eg. ffmpeg, IIRC).

Pourquoi un compilo pour Cortex-M0 avec sa libc associée ne conviendrait pas pour la plupart des développements sur Cortex-M3?

Si tu considères une famille de CPU ARM, alors oui, une toolchain ciblant le plus petit dénominateur commun de cette famille va générer du code tournant sur tous les CPUs de cette famille, même si de façon non-optimale dans la plupart des cas. En fait, le compilo, c´est pas trop grave, avec des flags de compil, on peut choisir un autre processeur. Par contre, la libc, une fois compilée, c´est marre.

Dans le monde de l´embarqué, les resources sont souvents contraintes, et notamment l'alimentation pour les mobiles, par exemple. Faire tourner du code optimisé pour le processeur réellement utilisé, ça peut faire gagner quelques miliwatt par-ci, par-là, et pof ! deux heures d'autonomie supplémentaire !

Après, il peut y avoir des flags de compil' pour le soft-float/hard-float par exemple.

Avec gcc, on peut (même si c´est loin d´être trivial) compiler une toolchain 'multilib' qui utilise les flags de compil pour savoir quelle libc utiliser. Reste qu'il faut quand même compiler la libc autant de fois qu'il y a de combinaisons possibles de ces flags de compil.…

Quand on voit que la compilation de GCC dans buildroot pour un système sur cible ARM "simple" est une des étapes les plus longues

C´est pour ça qu´il y a l´option pour utiliser une toolchain externe.

Dans le principe, tu construit ta toolchain une fois pour toutes, et ensuite tu dis à buildroot où la trouver. Comme ça, tu perds pas ton temps à chaque fois.

Hop,
Moi.

Pour ARM, c´est vraiment un mode très compliqué. Rien que pour le calcul flottant, c´est compliqué :

• soft-float ; hard-float avec: VFPv3, VFPv2, Neon, Maverick, FPA, iwmmxt…
• ABI des flottants : hard ou soft (utilisation des instructions hardware, mais passage des flottants comme pour du soft-float, sachant que l´ABI hard est différente de l´ABI soft…)

Ensuite, comme dis précédemment :

• ARMv4, v5, v6, v7, bientôt v8?
• optimisé (ordonnancement des instructions) pour :
  • v5 : XScale, ex93xx, mpcore…
  • v6 : cortex-a8, etc…
  • etc…
• etc…

Pour ARM, à l´époque où j´avais compté, j´étais arrivé a plus de 2048 combinaisons valides possibles… 8-O

Et puis pourquoi aussi les chaînes de compilation croisée, avec des combinaisons plus ou moins nombreuses (plutôt plus que moins, d'aileurs…) pour toutes les architectures :

• MIPS : 32 et 64 bits, trois ABI…
• PowerPC : 32 et 64 bits, au moins 4 ABI, des SoCs hyper variés…
• Alpha : Heu…
• AVR32 : avec ou sans MMU (IIRC)
• Blackfin : avec ou sans MMU (IIRC)
• ix86 (eg. geode est un i586 spécial, etc…), 32 et 64 bits, avec/sans MMX/MMX2/SSE/SSE2/SSE3/SSSE/SSSE2/3DNow/…
• or32k
• …

Et ce avec différentes libc, compilées pour chacune des variantes d´optimisation possibles, etc…

Et tant qu´à faire, différentes versions de binutils, de gcc (avec ou sans GRAPHITE, avec ou sans LTO, etc…), différentes versions de chaque libc (ben oui, certaines ont des bugs ou des fonctionalités supprimées (eg. glibc >= 2.14 ne permet plus de développer des applis utilisant les RPC)…

Bon, bref, à part packager quelques toolchains, qui de toute façon ne couvriront qu´une petite partie des gens intéressés, et pour quelques cibles trés visibles, c´est pas gagné.

Et je parle en connaissance de cause : je maintiens crosstool-NG (cité plus bas), j'ai déjà présenté le sujet à trois conférences (ELCE '09, ELCE '10 et FOSDEM '10), et faire des chaînes de compilation croisée fait partie de mon boulot (aussi)… Et pour plus d´infos, je devrais (à confirmer) donner une conférence sur le sujet aux RMLL 2012.

Bref, que du bonheur… :-p

Hop,
Moi.

Kamoulox!

Peut-être que son clavier s´est blo

sur [m]a carte carte grise […] il n'était pas écrit Renault mais Opel

Quand même, tu pourrais acheter français… ;-)

Hop,
Moi.

on leur dit ou pas ?

Heu… Est-ce vraiment la peine de le dire ? ;-)

Hop,
Moi.

Je propose que DLFP migre vers une solution d´avenir : le BBS

Le BBS, c´est le futur !

Hop,
Moi.

on suppose que les modifications ¹ d'une ressource se feront très rarement
¹: et même les modifications lors d'accès concurrent.

Bien vu ! Merci pour la précision.

D´un autre côté, lire à des données qui ne sont jamais modifiées, c´est un peu inutile… ;-)

Hop,
Moi.

Mais en fait c'est le contraire, la mémoire transactionelle est surtout utile lorsqu'il y a de la contention.

Au contraire. S´il y a contention, alors la mémoire transactionnelle implique que les transactions vont être refaites plus souvent que nécessaire. Dans le case de forte contention, les verrous sont plus adaptés.

• peu de contention --> mémoire transactionnelle
• beaucoup de contention --> verrous

Encore une fois, la mémoire transactionnelle est un mécanisme optimiste, qui suppose que les différents accès à une ressource ne se feront que très rarement en même temps, et donc préfère perdre beaucoup de temps (annuler la transaction, et refaire le travail) de temps en temps, plutôt que perdre un peu (prendre un verrou et le relâcher) à chaque fois.

Hop,
Moi.

Ce qui ne répond pas à sa question sur le changement de fréquence.

Mais qui répond à sa première question, même si elle n´était pas très explicite :

[nouveau] dans combien de temps/quel kernel ?

La fréquence, c´était sa seconde question. ;-)

Hop,
Moi.

on tombe sur la présentation du fond d'écran sur clubic

Bon, donc c´est a priori prévu pour être utilisé comme fond d´écran, au moins.

Merci.

Hop,
Moi.

voici une Nimage

C'est beau, un data-center la nuit ! :-)

Sinon, qui est l´auteur, et quelle est la licence de cette image ? J´aimerais bien la mettre en fond d´écran de mon netbook…

Hop,
Moi.

Réponse a ta question :

There's really no good reason for us to be in here anymore, we have to maintain this ABI anyway to avoid angering people.

Hop,
Moi.

Et surement d'autres que j'ai raté.

En effet : ratées.

;-)

Hop,
Moi.

Quand une ressource est partagée, 99,9% du temps, il n'y a pas de contention sur cette ressource

1/ je souhaiterai savoir d'où tu tire cette information

La probabilité est liée à plusieurs facteurs (je ne connais pas l'équation, cependant) :

• la taille de la ressource critique, et donc le nombre d'instructions pour la lier et la modifier, et donc le temps CPU passé en section critique --> t_crit
• le nombre d'instructions exécutés par chaque processus en dehors de la section critique, et donc le temps CPU plus le temps d'éviction (processus qui n'est pas élu pour tourner sur le CPU) passé en dehors de la section critique --> t_triv
• le nombre de processus qui veulent accéder à la ressource critique --> nb_procs
• le nombre de CPU utilisables --> nb_cpu

La probabilité évolue ainsi (à mon avis) :

• augmente avec t_crit
• augmente avec nb_procs
• augmente avec nb_cpu
• diminue avec t_triv

Dans la plupart des cas, le critère le plus important est t_triv, donc la probabilité de contention est faible, très faible. Par exemple pour deux processus qui exécutent l'un 100k et l'autre 50k instructions hors section critique, et partagent une section critique de 20 instructions, et qui tournent en permanence (toujours élus, sur deux processeurs) :

Pcrit(x) : probabilité que le processus x ne soit pas dans sa section critique.
Pcritsys : probabilité qu'aucun processus du système ne soit dans leur section critique.

Pcrit(0) = 1 - (20/100000) = 0.9998 = 99.98%
Pcrit(1) = 1 - (20/50000) = 0.9996 = 99.96%
Pcritsys = Pcrit(0) * Pcrit(1) ~= 0.9994 = 99.94% (arrondi par défaut)

50k instructions, ce n'est déjà pas beaucoup, quand tu vois le nombre d'instructions exécutées pour afficher une fenêtre à l'écran, par exemple.

Et les systèmes dans lesquels un très grand nombre de processus (>10) se battent pour la même ressource critique, est assez faible.

Alors oui, 99.9% est un nombre tiré de mon chapeau. C'est peut-être plus, peut-être moins ; mais assez proche de la réalité. Dans la plupart des cas, ça ne doit pas descendre beaucoup en dessous de 99%.

Hop,
Moi.