HS New Amiga Sports Programmable Co-Processor, Dualcore PPC - Page 1

Tiens, suis-je visionnaire (une fois de plus) ? Je viens de lire la news suivante sur OsNews :

http://www.osnews.com/story/22693/New_Amiga_Sports_Programmable_Co-Processor_Dualcore_PPC

Or il y a de celà bientôt 6 ans, je proposais quelque chose de similaire :

topics/45659-atari-68kpowerpccoldfireemulation

Dans l'ESP-1 y'avait un Xilinx programmable à volonté, là c'est un véritable co-processeur dans la lignée du Transputer (ATW 800 ?) : je parie que dans le monde Amiga y'en a qui vont bientôt s'amuser grâve...

Kochise

Eh oui, nous avons toujours cru en ton potentiel de grand visionnaire, mon bon David !!

Quand je lis ça, je pense tout de suite à la JagCF : le DSP est aussi programmable, dans le sens où son jeu d'instructions est défini en cours d'exécution.

Quand on voit débarquer des systèmes aussi "ovniesque", c'est toujours difficile au début de se faire une idée je trouve. Mais finalement ce genre d'innovation a peut-être bien de l'avenir !

Je me rends mal compte des perfs qu'on peut atteindre avec ce genre de système. Pour l'instant, c'est juste "pas standard" et assez confidentiel. Il faudrait des études pour comprendre comment ça peut être puissant, des benchs pour montrer à quel point, mais le concept est encore un peu jeune pour avoir été exploré peut-être.

Je me demande côté compilo s'il il existe une seule target GCC pour un tel proc programmable. Ca doit être un sacré morceau d'écrire un optimizer pour ce genre de target !!

Coté perf, y'a ce que le proc est capable de traiter, et ensuite y'a ce que la mémoire est capable de fournir comme data au processeur. Si ton CPU fournit un indice de traitement data de 100 (genre il traite 100 MiB par seconde, c'est un indice fictif) la mémoire doit au moins être capable de délivrer le double (100 MiB en lecture pour apporter les data au CPU, et 100 en écriture pour stocker ça en mémoire) Si ton CPU fait 50 et ta mémoire 200, t'iras à 50. Si c'est l'inverse, ton CPU à 100 mais ta mémoire à 50, bwaaa t'iras à 25 (débit lecture). L'exemple du Falcon030 avec son bus 16 bits à 16 MHz est la preuve la plus flagrante de ce problème. Tout comme donner à becqueter au DSP par le port HOST 8 bits, octet par octet, alors qu'il tourne à 32 MHz...

Kochise

Kochise (./3) :
Si c'est l'inverse, ton CPU à 100 mais ta mémoire à 50, bwaaa t'iras à 25 (débit lecture).

Tu oublies le cache
(et heureusement qu'il existe, sinon ce que tu as dit serait vrai et les machines se traîneraient lamentablement)

Ouais m'enfin le prefetch du 68000 ou le tout petit cache du 68030, c'est pas ça qui va faire vraiment la différence, surtout si tu pompes 100 MiB de données par seconde (le cache de 256 octets représente 0,00000244140625 Si on table sur un cache de 8 KiB ou plus, là ça commence à être interressant (table de mu ou DCT en cache, par exemple)

Kochise

OK, mais vu le processeur dont ils parlent dans l'article, on peut supposer qu'il a un cache de taille décente

Oui, dans ce cas, effectivement Coté compilo, tout dépend si tu cherches à te prendre la tête avec un modèle académique à-la-con, ou utiliser des frameworks retargetables comme l'excellent LLVM. Dans ce cas, c'est quasi-peanuts de pondre un nouveau compilo, faut juste lui fournir les tables d'opcode et les flags de condition modifiés, et ça passe en général assez bien

Kochise

Ce que je voulais dire, c'est que si un processeur permet de redéfinir son propre jeu d'instruction en cours d'exécution, alors le compilateur est face à davantage de choix pour déterminer le jeu d'instruction optimal pour un segment de code donné.

La question de savoir sur quel segment de code on se base pour chercher un bon jeu d'instruction est d'ailleurs très intéressante. Juste un exemple : changer de jeu au beau milieu d'une triple boucle hyper utilisée, c'est par exemple pas très malin, mais comment le compilo peut-il le deviner ?

J'aimerais bien savoir ce qu'en pense notre expert ès-compilation national :



Seb, tu as entendu parler autour de toi de ce genre de proc (reprogrammable) et des techniques d'optim' associées ? Il y a de la recherche là-dessus ? des benchs ?


Pour aller plus loin dans la discussion, il y a aussi des questions nouvelles qui se soulèvent : selon que le jeu d'instruction est X ou Y est actif, un même opcode (en cache par exemple) peut avoir deux significations différentes. Difficulté supplémentaire pour interpréter du code désassemblé ! Il faut savoir quel est le jeu d'instruction actif au moment où le code est exécuté. Ca rappelle les joies du code généré

Non non, le code ne change pas en cours, c'est plutôt dans l'idée de Transmeta et du Crusoe de pouvoir avec un CPU avec des ALU et des ARU de base et tu définie ton propre assembleur par code morphing. Donc t'injectes un pseudo micro-code perso au boot et ensuite tu peux utiliser le CPU à ta convenance, avec le jeu d'instructions que tu lui as défini. C'est comme ça qu'ils émulaient le x86, mais en principe il était possible démuler n'importe quel processeur.

Kochise

Ah ok, donc je rêvais un peu finalement. Ca peut pas changer en cours d'exécution en fait. C'est logique au fond, et ça rejoint ce qu'en dit Torvals : si on commence à faire ça, ça ouvre la porte à des trucs horribles.

Torvals
(...) Transmeta has never released enough details to [go to Crusoe native mode] anyway. Largely for simple security concerns - if you start giving interfaces for mucking around with the "microcode", you could do some really nasty things.

C'était fou cette techno Transmeta quand même... Très fort la démo d'exécution mêlée de code x86+picoJava !

Mais finalement, rajouter du support m68k ou PPC, il ressort que c'était juste une histoire de VM à coder... et à placer dans la flash... Sauf que donc ils n'ont jamais expliqué comment faire et que même dans leur boîte, seules des machines de dev spéciales pouvaient le faire.

Alors tant pis pour eux. Leur secret aura disparu dans leur tombe, mais y'a pas à se lamenter : des VM on n'est pas obligé d'avoir un transmeta pour en faire tourner !

Cela dit, j'imagine que comme pour la liquidation aux enchères des matériels de JTS, il y en a bien qui vont surveiller les liquidations pour récupérer ces machines de dev totalement uniques en leur genre, hihi.

stabylo (./10) :
Alors tant pis pour eux. Leur secret aura disparu dans leur tombe, mais y'a pas à se lamenter : des VM on n'est pas obligé d'avoir un transmeta pour en faire tourner !

Faux ! C'est Intel qui a récupéré le bébé et s'en ai largement servi pour les Pentium M (il me semble) technologie à la base des Atoms, ce qui leur confère leur étonnante efficacité et leur très très basse consomation.

Kochise

Tiens, j'ai retrouvé trace de la chôôôse :

http://www.reactivedata.com/Products/Legacy_Disk_and_Tape_Emulators/Single_Board_Computer/ESP-1/index.php

Kochise