Perso, j'ai commencé avec le motorola 6800.
Fallait rentrer le code machine à la mimine.
Ca rends humble par rapport aux millions d'instructions générées
actuellement.

--
Phil



"Pierre Y." <pierre.y@gmail.com> a écrit dans le message de news:
fo27tu$rrh$1@sd-6836.dedibox.fr...
> Flo a écrit :
>> Pierre Y. a écrit :
>>> Pour moi c'est comme de la plomberie, un métier inconnu dans lequel il
>>> n'existe que des spécialistes, qui se perd et pour lequel il n'existera
>>> bientôt plus de remplacants.
>>
>> ftp://download.intel.com/design/Pentium4/manuals
>
> Plus rien de neuf depuis le P4 ?
>
>>> Donc je prend ça pour ce que c'est, une prouesse technologique sans même
>>> ce petit quelque chose qui me titille le dessous de la curiosité et je
>>> suis bien content que d'autres sachent le faire à ma place.
>>
>> pourtant t'as bien du faire des µP à l'IUT non?
>
> Yep. Et ?
>
> Je ne sais pas ce qu'il en est côté jeu d'instructions du CPU mais selon
> moi, c'est plus intéressant de savoir optimiser l'utilisation de multiples
> coeurs (et d'avoir des outils qui permettent de le faire au niveau du
> langage) que de réimplémenter en moins bien les algorithmes qui ont déjà
> été optimisés par d'autres.

1 pressionnant.
Je dirais même 2pressionnant.
Chapeau !

--
Phil



"Pierre Y." <pierre.y@gmail.com> a écrit dans le message de news:
fo2926$sa3$1@sd-6836.dedibox.fr...
> sheep a écrit :
>> L'assembleur est un langage comme un autre.
>
> Euh, non. L'assembleur N'EST PAS un langage comme un autre. Aucun langage
> n'est comme les autres d'ailleurs sinon on ne verrait pas autant de code
> dégueulasse puisque tout le monde saurait maîtriser à la perfection toutes
> les finesses de tous les langages.
>
>> Rien de mystique dans cette affaire.
>
> Rien de mystique si ce ne sont les communautés de "gourous", comme dans
> tous les domaines de l'informatique. Gourous... Mysticisme... Bref.
>
>> Et en plus, cela permet de voir le génie du compilateur
>> en regard du code Delphi d'origine.
>
> Le génie du mec qui a écrit le compilateur.
>
>> L'utilisation de composants tout faits ?
>
> J'ai du sauter une étape. Soit, les composants, moi ça me va tant que
> c'est les autres qui les font ;-)
>
>> Oui, bien sûr, on ne va pas ré inventer la roue à chaque fois !
>> C'est vrai qu'aujourd'hui, on en est même plus là.
>> On dit ce qu'on veut de manière graphique, un générateur de code
>> pisse un machin qui est compilé ou interprété et roule.
>
> Certains ont besoin que l'informatique devienne une activité productive,
> comme dans l'industrie, on produit beaucoup avec une qualité constante,
> une richesse fonctionnelle en constante augmentation avec le même nombre
> de doigts et de cerveaux et le même nombre d'heures de sommeil.
>
>> ... Et quand ça merde, bonjour le déverminage !
>
> Les nouvelles méthodes de programmation (celles dont les utilisateurs de
> Delphi n'ont jamais entendu parler en général) insistent sur l'écriture de
> tests unitaires, tests d'intégration continue, tests de non régression. Le
> tout autmatisé. Ca change la vie. D'ailleurs W.Ehrhardt dispose dans ses
> librairies de tout un framework de test. C'est bien, c'est un exemple à
> suivre. Sauf que ces exemples ne sont pas automatisables. (Par
> automatisable j'entend qu'il existe quelque part un truc qui fait un
> checkout des sources à chaque changement dans le repository, compile,
> vérifie que ca a compilé correctement et lance le framework de test
> d'intégration, de non régression... lorsque tout est passé, il génère un
> snapshot des sources ou des exécutables pour les tests manuels. Puis il
> averti les développeurs que les tests continuent à passer.) A l'arrivée il
> y a plus de test que de code, mais... finalement... n'y a-t-il pas, dans
> le wild wild world, plus de code qui utilise un outil (compilateur,
> composant, framework, librairie...) que de code dans l'outil lui même ?
>
> Tenez, un truc m'a bluffé, je suis le projet Rubinius, une machine
> virtuelle pour Ruby basée sur les concepts de SmallTalk, la crème de la
> crème en matière de conception de machine virtuelle.
>
> Le projet est géré par Lighthouse (une application de suivi de projet,
> comme Mingle) et GIT (le SVN de Linus). A chaque commit, le code est
> recompilé et les tests d'intégration sont lancés. Le résultat des tests
> est posté sur le chan IRC de #rubinius sur FreeNode.
>
> C'est rigolo à voir, les développeurs causent des problèmes qu'ils
> rencontrent, et de temps en temps on voit les messages des bots qui
> observent les commits, réalisent les tests et postent les résultats.
>
> Les tests dans rubinius sont basés sur rspec, un framework de tests écrit
> en Ruby qui permet de décrire un test comme une histoire, un scénario en
> somme et sont la synthèse de tous les tests existants dans la machine
> virtuelle Ruby de référence (MRI : Matz Ruby Interpreter) et de ceux du
> projet JRuby (un interpréteur Ruby pour la JVM qui garantit
> l'intéropérabilité des classes Ruby avec le code Java et vice versa)
>
>> Cela dit, dans certaines units Delphi (D6), il y a toujours de
>> l'assembleur
>> (Ex : dans SysUtils, la procédure DivMod etc ...)
>
> Oui et dans D2006/D2007 il y en a encore plus : le gestionnaire de mémoire
> et toutes les fonctions de traitement sur les chaînes réalisées par les
> membres du projet... FastCode.
>
>> Bon , j'accepte d'être traité de dinosaure.
>
> Je dis que je suis incapable de faire ce que tu as fait, que je n'en
> éprouve pas le besoin et que je suis content que des gens comme toi
> sachent le faire. Je ne te "traite" pas de dinosaure.
>
> Finalement, toute cette discussion pour en arriver où ? Habituellement
> c'est le djob de Merlin, François et Jean de philosopher sur le boulot de
> développeur et sur les avantages et les inconvénients des langages...
>
> @+
>
> PS : J'accepte d'être traîté de con s'il le faut.