COSMOS : Lettre d'amour
-
Tu as raison, toutes les involutions que tu cites sont vraies du point de vue d’un développeur ASM.
Cependant, je pense qu’aujourd’hui le travail des developpeurs n’est plus à l’écriture du code machine pour plusieurs raison qui sortent du cadre de ce topic. Mais on peut juste citer le fait que l’optimisation tend à devenir inutile, que les gros programmes actuels demanderaient beaucoup trop de ressources (humaines) pour être codées en assembleur et seraient attachées à une architecture etc.
Aujourd’hui c’est le compilateur qui s’en charge et ce dernier a besoin d’une cible simple pour ajuster le code machine. A ceci se rajoute les micro-optimisation processeurs telles que l’hyperthreading ou la prédiction des branchements, pour ne citer que celles la, qui sont plus simples à mettre en oeuvre avec des processeurs “simples”. Donc avec des instructions atomiques qui font le moins de choses possibles.
Plus généralement, d’un point de vue developpeur comme utilisateur, l’important n’est-il pas l’application en elle même ? Je veux dire que – ok ça peut être fun de faire une appli sur une cible particulière – mais dans le cas général a-t-on réellement envie (besoin ?) de se préoccuper du type de processeur ?
Pour finir sur ton commentaire “<span class=”normal” style=”font-size: small;”>PPC développé par des personnes qui ne connaissaient RIEN à la programmation” </span><span class=”normal” style=”font-size: small;”>n’est-ce pas tout a fait logique en fait ? On ne leurs demande pas de faire un processeur facile à utiliser mais un processeur qui maximise les performances brutes car de toute façon pratiquement personne ne va faire du code machine !
</span>A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1Compte AI de l’utilisateur Cosmos et messages supprimés à la demande de ce dernier !
Non tu ne parles pas dans le vide, la discution est très interessante !
Pour le côté ludique, interet particulier pour un CPU, je ne peux pas te contredire dans le sens ou chacun voit midi à sa porte. Si ce que toi tu aimes vraiment, c’est connaitre extrémement bien le cpu pour en tirer le maximum de performances et bien c’est très bien ! Je peux même te dire que j’aimerai savoir faire ça, en être à ce niveau c’est top ! Il y a besoin de gens pationnés comme toi !
Mais de la à dire que c’est l’essentiel, que pousser les gens à programmer en C c’est une perte de temps ça me semble un chouille exagéré !
Dans une vision plus large, non restreinte aux amiga classiques avec un 68060 max. Je pense qu’au contraire pousser les gens à développer en asm c’est justement les pousser à véritablement perdre du temps ! Pourquoi ? Parceque c’est se focaliser sur le fonctionnement du processeur plutot que sur l’application en elle même. ça fini par des fichier éxécutables qui remplissent leur tâche mais qui sont moins évolués au niveau utilisation (plus difficile de penser architecture ou même ergonomie lorsqu’on est focalisé sur le code asm !). Après, c’est vrai que dans certains cas ça peut être important lorsqu’on veut optimiser une routine particulière … Avant c’était obligatoire pour la majorité des routines car le manque de puissance était plus important. Mais aujourd’hui avant d’en arriver à optimiser les instructions il y a déjà beaucoup de temps à passer pour optimiser d’autres choses plus haut niveau !
Et puis quid de la portabilité ? Une fois que tu t’es tapé tout ton programme en assembleur aux ptit oignonx pour ton processeur, tu va le faire pour tous les processeurs du monde ? Sans aller dans les extrèmes (java python etc), le C apporte quand même un certain confort, un compromi interressant non ?
Pour ton exemple de taille d’éxécutables, je ne vois pas ou tu veux en venir ? Il est normal que les éxécutables PPC soient plus gros car il faut plus d’instructions pour faire la même chose ! Mais ça ne veut pas (toujours) dire que ça s’éxécutera plus vite ! Si le code plus “gros” utilise moins de branchement ou maxime l’utilisation des pipelines, pourquoi pas !
Dernier point, ou plutôt question en fait:
Es-tu certain qu’un programmeur ASM puisse encore rivaliser avec un compilateur C sur les architectures d’aujourd’hui ? Je veux parler des CPU qui éxécutent pratiquement 10 instructions par cycles ! Pour ma part j’en doute, ou alors pour des routines vraiment spécifiques… (Mais je ne suis pas developpeur asm 🙂 )
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1
Compte AI de l’utilisateur Cosmos et messages supprimés à la demande de ce dernier !
@k1200rs21
Ouais, c’est cool. Ce petit projet, monté dans un garage, enchaîne amélioration sur améliorations.Du point de vue de notre marché, si l’on oublie le support fpga qui l’handicape, on a l’impression qu’il flirt avec les cpu actuels (pipeline, gestion du cache, optimisation des instructions, 64 bits, etc.).
Par contre, qu’en est-il de l’hyperthread, du multicore? Est-ce que c’est à porté de ses designers? (je lance cette question indépendamment du fait que l’amiga os est loin de tout ça).
oui je pense que tu as raison, même si j’aime bien le concept hybride des blizzard ppc, un “simple” 68k au gout du jour aurait surement été mieux pour tout le monde… Qu’ils se rassemblent tous pour finir le natami en somme…
@seg:Je ne pense pas que ça soit prévu pour tout de suite car de toute façon aucuns des OS amigalike ne supporte le multi-processing actuellement donc l’interet est plutot limité (à court terme en tout cas !).
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1
@Cosmos : Même si l’idée séduit, et pourrait “en apparence” paraître comme étant “rassembleur”, un soucis se pose :
Un 68080 à 1ghz, c’est techniquement et technologiquement possible ? Si oui, comment ? Je t’avais déjà posé la question mais tu n’as jamais répondu la dernière fois .. Préférant me qualifier d’abruti ou d’imbécile …
Vas-tu déroger à la règle et enfin répondre ou continuer à te croire supérieur en évitant la question qui dérange en m’insultant (ce qui démontrerait encore une fois que ma question dérange)… Non … Sinon “faire semblant de ne pas avoir vu la réponse de AmiDARK” …. mais ça changera pas le problème de l’existence de la question …
Je devrais peut-être ouvrir directement un fil de discussion pour te poser la question … Ce serait plus simple … Puis je ferais un petit up de temps à autre en attendant que la réponse “qui ne viendra jamais” vienne … Car il est une réalité qui est que, si Motorola ont arrêté les processeur à instructions complexes c’est parce que d’un point de vue technologique, il n’était pas possible (à l’époque) de faire mieux sans provoquer de risque de stabilités du CPU …. @amigadark
Techniquement c’est possible en faisant une architecture hybride comme sur Intel, c’est à dire que les instructions visibles par le développeur sont bien les instruction 68K (CISC) mais qu’en interne elles sont traduites en instructions plus simple (du RISC donc !).
Je ne sais pas si c’est ce qui est fait dans l’APOLO core, mais ça ne m’étonnerai pas vu les arguments qu’ils avancent en terme de pipelining et autres technologies.
Par contre je ne pense pas que ça soit faisable dans un FPGA… déjà atteindre 400Mhz ça serait pas mal du tout ! Et après tout, un CPU à 400Mhz avec pleins de modules d’acceleration pour les tâches régulières (h264, h265, mp3 etc) ça serait déjà un pas de géant !
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1@AmiDARK
Oui, techniquement, c’est possible.
Financièrement par contre…Mais à mon humble avis, la première (longue) étape est de dessiner un cpu à jour, fiable, sans bug, et parfaitement tuné.
Une fois tout ça dans les cartons, on peut se mettre à rêver à prospecter des clients potentiels pour d’autres applications, et ainsi avoir les moyens (via levée de fonds) de fondre un cpu brut de brut à 1, 2 ou 3 ghz.Pour ce qui est du choix de Motorola, je pense qu’il a été politique.
Personnellement, au moment des 68040 et 68060, je n’ai pas trouvé Motorola investi dans les semi conducteurs. Il y avait une marge entre le commerce/marketing et la technique.
Ce n’est pas sans rappeler l’histoire de Commodore.Bref, il n’y a qu’à voir l’histoire de Motorola qui se sépare de sa division semi conducteur pour se concentrer sur la téléphonie, et ensuite être racheté par Google, pour finir dans les pattes de Lenovo.
C’est comme si Motorola avait été vérolé de l’intérieur par des abrutis qui l’ont jeté aux caniveaux.Motorola, c’est l’histoire d’une belle boîte gangrenée par des gens à la logique purement financière. Ils n’avaient pas de vision d’avenir. Leur vision, c’était de faire tomber l’argent à court terme.
C’est comme ça que je l’interprète. @cclecle : Donc si il y a “émulation” des instructions du 680×0 … On est plus sur du 680×0 et on perd en performance (dans la traduction).. On est plus vraiment dans “l’optimisation” que Cosmos aime tant …
Cosmos parle d’un 68080, c’est à dire un VRAI processeur à instructions complexes…
@Seg : Tu as des arguments derrière pour le “Techniquement possible” ? Car si Motorola ont arrêté et changé d’optique, c’est qu’il y a des raisons… non ?Pour ma part, par rapport à la technologie nécessaire aux processeurs à instructions complexes, je parle de limites/constraintes de chaleur (refroidissement), dimensions et espace nécessaire dans le CPU, etc … Un 68080 à 1Ghz, est-ce réellement possible ?
PS : Et une réponse simple genre “oui c’est possible”, ce n’est pas suffisant, je demande des arguments techniques fiables !
@AmiDARK
En ce qui concerne le choix de Motorola, il me semble y avoir répondu.
Je ne suis pas dans les petits papiers de Motorola mais je pense, à mon humble avis bien sûr, que le choix d’abandonner le 68k n’était pas lié à une contrainte technique. D’ailleurs, c’est la première fois que j’entends parler de cette hypothèse. Motorola voulait faire table rase sur le CISC pour passer au RISC, car c’était “la mode”. Et c’était censé aller bien au delà du CISC, en terme de performance, à terme. De plus, on devait rentrer dans l’ère du 64 bits avec le RISC…Sauf que Intel n’a jamais abandonné son jeu d’instructions. Il a continué à être compétitif sans rien y enlever. Au contraire, Intel en a rajouté.
Pour faire genre (on sait jamais), Intel a quand même développé son RISC personnel, l’Itanium. Ils ont fait du bénéfice avec mais c’est clairement pas la vedette du groupe.Sinon, quand je dis “oui, c’est possible”, c’est tout simplement avec les technos actuelles. Il n’y a pas de contrainte 68k, tout comme il n’y a pas eu de contrainte pour pousser le x86 jusqu’à notre ère, tout en restant compétitif par rapport à un cpu RISC. Pourtant, le x86 était bien plus mal gaulé que le 68k pour être poussé aussi loin.
Si tu vois un problème dans le 68k que nous ne voyons pas, n’hésite pas à nous en faire part aussi techniquement que possible.
@amidark: Je ne vois pas ou est le problème, Il n’y a aucune émulation, tout est bien là, en vrai, en hardware. Juste que les instructions sont subdivisées en micro-instructions pour des raisons de performances ! En réalité cela sert à diviser le travail en plus petites tâches, ce qui permet de réduire la logique entre les registres et ainsi pouvoir atteindre des fréquences de fonctionnement plus élevées… Cela sert aussi à mieux paralléliser les instructions.
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1 Gunnar dit que son cor fait déjà plus de 400mips et explose un ppc 603 voir ppc 604
et la prochaine évolution du nom de ARRIA pourra être comparé au g3!!!
http://www.apollo-core.com/knowledge.php?b=1¬e=890&z=DuLusU
https://www.youtube.com/channel/UCndcNrLt5Y5SDobFQbjtCaQ?view_as=subscriber
Vivement la version 1200 !
Moi qui n’ai connu qu’au maximum un 040 à 33Mhz côté 68K Oo, ça va faire tout drole lol.
Au fait, j’ai cherché mais pas trouvé d’info concernant la license du core APOLLO ? C’est pas open-source manifestement ?
A600 + 604n + RTC + Vampire V2 600, Coffin R54 / wb3.1.4.1
A1200 + Vampire V2 1200, wb3.1.4.1
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Général › COSMOS : Lettre d'amour
