Infos sur la Vampire
-
Désolé je me suis mal exprimé , je parlais bien de la quantité de mémoire retirer des 128mo et attribué à de là chip .
merci pour la réponse qui est 4mo donc ma 604n me servira à rien une fois la good 3 disponible .
Je ne dis pas que ça ne se fera pas, peut être bien que oui, peut être bien que non. On en discutais pas plus tard que cette après midi. Mais actuellement, on a 4 MB de chip, le reste en fast, et pas de RTG, car la carte RTG est désactivée pour le moment dans les core de test (pour une raison toute simple : il faut mettre en place un mécanisme de switch entre le RTG et l’AGA, sinon la carte ne sait tout simplement pas quel signal afficher).
Hello
Bon on reviens sur le FPU
Petit rappel
Le core Apollo a une implémentation du FPU mais le Vampire ne l’implémente pasMais voici du neuf Lu sur apollo-core.com:
« Jari Eskelinen:
>coder une softFPU
En tant que projet d’apprentissage personnel, j’ai commencé à travailler sur un SoftFPU.
Etonnament, il est déjà capable d’exécuter le générateur Mandelbrot (bien que sous les UAE seulement, certains problèmes avec Vampire, doit en discuter avec l’équipe).Gunnar von Boehn:
Voici le SoftFPU de Jari
Il y a bien sûr beaucoup à faire, mais son SoftFPU fonctionne vraiment et certains programmes mandelbrot, fractal etc. marchent 100% correctement déjàSimo Koivukoski:
Un premier test de la Soft fpu
FMath
KoopRate
You 7.42
A600 1.00
A1200 1.72
A3000 4.51
A4040 16.18 »SoftFPU: L’idée c’est que les intructions FPU non connues (puisque pas de FPU) générent des exceptions cad des traps traitées par Exec dans un programme qui fait le calcul (prog par le CPU = soft fpu) : C’est lent mais les applis sérieuses (genre Lightwave) devraient alors marcher
Effectivement, on peut lire l’info ici.
En théorie, ce soft fpu peut torcher un 68882. Ce serait bien que le mec mette ses sources en dp (si c’est pas déjà le cas), pour voir comment il a commencé à implémenter le truc.
Le principe, c’est de trapper les instructions illégales (inexistantes), de remplacer l’instruction illégale par un jsr ou un jmp vers la version « émulée » de l’instruction, d’exécuter le code et de revenir à l’instruction suivante. En gros, c’est faire un Oxyron Patcher qui gèrent toutes les instructions et registres manquants.
Je sais pas trop
La méthode « naturelle » d’implémenter ce genre de patch serait de s’appuyer sur les traps comme indiqué ici
http://wiki.amigaos.net/wiki/Exec_Tasks#Task_Traps
Je ne sais si c’est la méthode qu’il a utilisé…Mais je pense pas qu’avoir fait un forbid() doit changer grand chose car on reste alors toujours dans la même tache oui mais la trap y survient en superviseur puis traitement (cad SoftFloat dans notre cas) donc ça passe
Mais au final même si ça marche qu’avec les applis « propres » genre Lightwave ou Caligari24 ce serait déjà hyper cool 🙂
Alain
Edit: J’aurai tendance à penser que même sous forbid ça marche car on voit bien des gourous (=alerte système sur exceptions) sur des demos/jeux
Il n’y a pas de raison. Exec est accessible, multitâche ou pas.
La librairie ne sert que d’abstraction entre le cpu et le code. Donc, une fois l’exception rencontrée, le cpu saute sur le dispatcher d’exceptions d’exec. Le code d’exec saute sur la routine d’interruption du SoftFPU, puis retour à l’instruction qui suit l’exception. L’exception prime sur le task switching de toute manière, et elle se branle du Forbid() si ma mémoire est bonne. Ceci dit, c’est lointain tout ça…
Il s’agit d’une solution, au mieux, temporaire, au pire définitive. En effet, le fpu existe dans le 68080 mais, le soucis, c’est la taille du fpga de la Vampire qui n’est pas sûre de pouvoir le contenir après implémentation du chipset SAGA.
Ce problème ne devrait pas se poser dans la standalone, ou la V1200. Les deux devraient disposer d’un fpga avec assez de place pour tout contenir. En tout cas, ça semble être l’objectif.
>se branle du Forbid() si ma mémoire est bonne
Effectivement c’est bien le cas :
Forbid() : Prevents other tasks from being scheduled to run by the dispatcher […] Interrupts are NOT disabled.
Source:
http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0353.htmlAlain
Ça bouge autour de la Vampire:
– Le soft FPU permet maintenant de faire tourner des démos. C’est un peu « très lent » mais ce n’est qu’un début. L’important est d’abord de roder les mécanismes de surcharge avant de passer à l’optimisation. Je spécule, mais j’imagine que le code est en C et qu’il y a pas mal de route à faire avant d’optimiser le tout en ASM 080.
– Une solution permet de booter depuis la SD Card
– Des améliorations sur l’implémentation de l’AGA, ce qui permet de jouer, entre autres, à Slam Tilt AGA avec le son direct sur la sortie HDMI.
Pas mal pour une équipe de bénévoles!
A noter que l’équipe essuie régulièrement des critiques, parfois constructives, parfois non, mais que cela ne l’empêche pas de progresser à bon train vers l’objectif légitime qu’ils se sont fixés.
>soft FPU […] ce n’est qu’un début.
Exactement d’accord : je ne supporte pas les critiques que l’on voit un peu partout à propos de cette solution SoftFpu (de mecs qui ont jamais rien programmé de leur vie). En effet il s’agit d’une toute première version et qui obtient déjà des résultats honorables (meilleurs qu’un A3000)
Ce SoftFpu ne peut que s’améliorer : Ce genre de hack est assez perilleux à écrire/debugger donc applique certainement la regle des bons programmeurs « ne jamais optimiser durant la phase de conception/prototypage »
Donc quand des optimisations vont apparaitre la vitesse sera certainement multipliée et je pense que dépasser un A4040 est certainement atteignable ce qui serait déjà grandiose pour un A500 équipé d’une Vampire 🙂Quand à la démo Kioea rien ne dit que ce soit le fpu qui la ralentit… On me dira si c’est le RTG ou AHI c’est préoccupant aussi… c’est vrai
>Je spécule, mais j’imagine que le code est en C
Effectivement il est fort probable que Jari a utilisé une des sources C de FPU existante comme celle de l’émulateur Mac ShoeBill ou d’UAE
Sans même passer du C à l’ASM ce genre de source gère le byteordering ce qui devient superflu puisque le 68080 a le même ordering que 68040/68881 donc tout ce code de gestion pourra etre enlevéAlain
A mon humble avis, les solutions techniques ne manquent pas pour atteindre le fpu d’un 060@50mhz. Peut-être même le battre avec quelques ajouts au niveau du core. J’admets que je dis ça avec un peu les pieds hors sol. J’ai aucun moyen de tester une vampire pour vérifier mon assertion 🙂
Malheureusement, je ne sais pas si cette solution se donnera la peine d’aller jusqu’au bout du possible, car il n’est pas exclu qu’un fpu hardware soit intégré in fine.
Il y a en effet pas mal de progrès, tous les jours en fait.
Concernant le SoftFPU (femu), l’implémentation est intéressante, développé sur UAE (sans la coche FPU). La méthodologie est le mécanisme d’abord, pas les perfs. Jari a rejoint la team et est bien motiv. Sur la Vampire, femu sera intégré au Kickstart et sera donc accessible partout (le kick étant protégé en mémoire, et toujours accessible).
Ensuite, pour avoir vu le code, le programme prend en charge naturellement les traps (line F), décode les instructions trappées, décode les différents cas de EA : effective address, (a0), d(a0), (a0,d0.w*2), etc… et les calculs sont tout simplement redirigés vers les mathieeebas/double .library (et oui, pas con en fait, ca économise du temps de dev), ensuite les registres sont mis à jour. Bref, c’est très propre pour un néophyte qui a sacrément bien décortiqué le M68000PRM.pdf. Ensuite, lorsque toute la mécanique sera bien en place, les calculs pourront être déplacés de ces .library vers du code custom ou, en partie, vers le core via une implémentation itérative et sélective (le core s’attachera a prendre à sa charge des composants dans la chaine FPU, par exemple les registres FPx et les FMOVEs, et quelques tricks pour optimiser les traps/context switch).
Clairement, l’objectif est d’abord ceci :
– Un FPU en soft, propre, permettant de faire tourner tous ces programmes qui ont été compilés avec 030fpu 040fpu par exemple, mais qui ne le justifient pas vraiment, ainsi ces programmes qui font appellent au FPU juste pour un PrintF(double) fonctionneront de manière transparentes, et çà c’est déjà une grande avancée pour les utilisateurs de Vampire. Beaucoup de programmes, comme çà, font appels au FPU dans des sous library statiques ou pas, dans des dépendances qu’on ne maitrise pas toujours. L’idée première de Jari est bien là, bien plus que pour les perfs.
– Valider l’implémentation avec des programmes plus lourds, même si c’est lent, mais au moins, avec des résultats corrects.
– Phase d’optimisations (Coté code _et_ coté core).
Attention toutefois, ce projet nécessite beaucoup de travail, ce n’est pas anodin et pas non plus un hasard si personne ne l’avait fait avant (sauf sur MacOS par des ingénieurs bien épaulés par Motorola). Donc çà prendra du temps. En tous cas, je suis personnellement ravi de cette solution qui n’apporte que du bon, car ca offre à gunnar une base sur laquelle il peut travailler pour ajouter le fpu petit à petit dans le core, et offre un solution pour les utilisateurs finaux en attendant. Le projet est aussi directement intéressant pour les autres systèmes FPGA, donc affaire à suivre de très près.
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
- Le sujet ‘Infos sur la Vampire’ est fermé à de nouvelles réponses.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire
