Infos sur la Vampire
-
Et un AmigaOS qui arrête de gourouter parce qu’il intègre le principe tout récent d’isolation mémoire, ce n’est pas envisageable ?
Ah oui, c’est vrai qu’on n’a pas les sources.
*soupir*
edit: ah oui arOS, ça doit intégrer la protection mémoire. Bon si ce n’est que temporaire cette restriction de doc, il ferait mieux de le dire clairement («le temps qu’on mette au point, on n’a pas de doc à fournir aux tiers» <- normal, et plus rassurant).
Sans même penser à la protection mémoire pour l’utilisateur final dont beaucoup sur le forum apollo disent que ca fait ramer, j’ai pu constater combien là bas était hostiles à l’utilisation du MMU pour les développeurs (muForce, muMem, Enforcer, etc). Pour cetains Vampire-fanboyz, les développeurs qui ont besoin de protection MMU sont de mauvais codeurs. Lol, dès fois je me dis que là bas certains planent à des km au dessus du monde réel:)
Par exemple ils continuent de privilégier l’ASM au bon vieux code C 😐 Bon ca se comprend un peu, car il n’y a pas de compilo C capable d’optimiser correctement pour l’hyper-threading et le AMMX. Mais sans docs sur les principes du 68080, faire un compilo optimisant relève de la pensée magique.
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)
>Ça veut dire quoi que «les specs de la MMU ne sont pas pour le grand public» ?
Il y a eu un message dans ce sens sur le forum Apollo mais je le retrouve plus: il a du être effacé avec le fil linux
Néanmoins je crois qu’il fallait pas le prendre au sens tragique mais plutôt comme:
– Les specs de la MMU évoluent encore et sont donc pas encore dispo
et/ou
– Comme la MMU ne sera pas identique à celle des 68040 ou 68060 nous ne voulons pas que des gens créent du code ne marchant que sur 68080 et donc la gestion de la MMU sera géré par Exec de manière transparente
et/ou
– Les développeurs vraiment intéressés pour créer des trucs comme « Enforcer » devront être en contact avec la team Apollo pour éviter des erreurs de design de leur appli>bêta testeurs sont sur v3 avec les vampire v2
Oui je crois aussi que juste des « morceaux » de v3 sont testés sur la vampire v2 car c’est un matériel réputé fiable
(je veut dire: si on testais core3/vampire2 on saurais pas lequel bogue puisque les 2 sont en tests)Au final on sent une grande confusion/effervescence
Car je pense que la Team (dont je fais pas partie) essaie de finir pour l’Amiga32 et ne veut pas se lancer ni se faire distraire sur d’autre projets (mmu,linux,3d,etc…)Y avait eu une question dans ce fil sur la 3d genre « Pourra t’on se passer de mediator/radeon si la 3d apparait sur la Vampire ? »
A mon avis aucune chance qu’un éventuel « Wazp3D optimisé Vampire » puisse concurrencer une vraie carte 3D récente mais elle pourrait éventuellement offrir une fonctionnalité 3d de base (lente et à faible résolution) permettant de lancer qques softs 3D 68k anciensPour s’en convaincre il suffit de faire un petit calcul:
1024×768 à 20 fps en admettant une dizaine d’instructions pour faire un pixel 3d = 1024*768*20*10 = 157 MIPS = on y est pas
On comprends alors aisément que pour faire mieux il faudrait le faire en moins d’instructions donc que le 68080 ait des instructions plus « puissantes » pour la 3D ce qui n’est pas le cas
actuellement (par exemple une pour pour lire/ecrire un pixel a une position x y en un cycle)Alain
>Pour cetains Vampire-fanboyz, les développeurs qui ont besoin de protection MMU sont de mauvais codeurs.
Je pense aussi qu’il s’agit de fans qui ont jamais programmés et ont jamais eu de gros Amiga et voient pas à quoi servent FPU/MMU ni combien de softs sérieux s’en servent
Pour ma part un jour j’ai installé Enforcer sur mon WinUAE et je l’ai plus jamais enlevé: périodiquement il voit les accès mémoire illégaux (bugs) de mes progs en développement : des erreurs qu’ils serait inadmissible de laisser
Je veut dire : une fois qu’on a un outil MMU comme celui là qui montre nos erreurs (montre sa merde) on ne peut plus les ignorer et croire béatement qu’on fait un code 100% correct car il plante pasPareillement je me suis créé un petit « tracker de mémoire » avec des walls qui me aussi dit si tout est bien libéré à la fin : je peut plus m’en passer sinon j’aurai l’impression de produire de la merde
>mauvais codeurs
Non l’apparition de bug est intrinsèque à la création/modification du code : on ne peut éviter d’en voir surgir car on est que des humains mais par contre ne pas les enlever ni même les voir là ça craintEn plus votre code peut être utilisé par « autre chose » qui fait des choses stupides ou inattendues et cela même si votre code a été désigné logiquement alors la bug survient
Un exemple: dans GMAP mon émulateur de jeux Game Maker on a un fonctionnement « objet » avec des scripts GML à la destruction d’un Objet (Ennemis,Héros,Tirs,etc…) or dans un jeu on avait dans ce script instance_destroy(objet); puis accès au variables de cet objet … détruit.Alain
Le MMU, c’est à la charge de l’OS, et pas du codeur , fort heureusement 🙂
Sauf peut-être dans le cadre du multitache coopératif, et encore même dans ce cas, il me semble que seul le respect du scheduling (ne pas bloquer le système en monopolisant les ressources) est à la charge du codeur.
Si je sors de ma zone mémoire avec un programme mal fichu, ça va coredumper , et le reste du système restera bien stable, merci l’OS (qui s’occupera au passage de fermer les flux ouverts, ce qui est bien pratique en cas de plantage pour ne pas se retrouver en plus à court de descripteurs de fichiers).
Mais peut-être est-ce plus différent sur les systèmes plus expérimentaux. Ça dépend ce qu’on appelle outil MMU, est-ce que mtrace (qui intercepte simplement les appels à malloc() et free(), pour voir si ça colle) ou valgrind (pré-analyse) rentrent dans cette catégorie, ou est-ce plutôt une notion à intégrer dans les debuggers systèmes genre gdb (je fais la distinction car il y a aussi des debuggers soft, genre le debug javascript dans le browser, mais bon voilà quoi 🙂
Alain, ton dernier exemple semble indiquer un plantage dû à un débordement dans une VM qui elle même déborde vers l’hôte (le «vrai» OS): dans ce cas c’est clairement un boulot pour la gestion mémoire de l’OS, ce n’est plus à toi de t’en préoccuper et ça ne fait pas de toi un «mauvais codeur» (faudra quand même corriger le bug hein :þ ).
Je n’aimerais pas être sur un OS qui se vautre suite à un plantage dans une VM (je ne parle pas de la para-virtualisation avec accès direct au matos pour des raisons de perfs).(edit: ah j’ai l’impression que tu parlais simplement de la mauvaise utilisation par un utilisateur de fonctions mises à dispo, j’ai lu trop vite.)
Bon j’arrête d’écrire des tartines…
Mod Hello à tous .
je lis avec attention tes commentaire de alain vu que je sais que lui est codeur. Mais un truc me chiffone sur quel base d info tu travails pour parler de la mmu du 68080 car perso j ai rien vu passez donc impossible de savoir quoi vas marche ou pas…
je vous vois parler de se que biggun doit devrai faire et cela me fait un peu marré en effet je pensse qu il y a 0,00000001/100000000 de chance que vos remarque ici soie lue par des personne qui pourrais faire qqc. De plus il faut savoir que le 68080 c est le bébé de biggun et que concevoir de processeur fait partie de son métier donc il dois savoir se qu il fait quand il code. Cela fait bien 8 ans qui est dessus. Donc a moin d avoir de gros gros gros arguments ca vas être chaud de le faire changer d avis… surtout si vous n avez jamais faite de programation processeur ou vhdl…
il faut aussi se dire que le 68080 est une évolution pas un clone de la game 680×0 donc normal de pas retrouvé tout 100% pareil et que le chose change même si ca l aire stupide
@thellier
+1La team est focus sur l’amiga32. Pas le temps de digresser sur d’autres sujets de discussion. La montée en tension (comme la suppression du thread linux) montre juste qu’ils sont short pour être prêt le jour J. Dans le sens où, soit il manque des fonctionnalités, soit les tests ne sont pas tous effectués (ou les 2 bien sûr). Des bugs sont potentiellement encore cachés. Ça ferait tâche pour une première démonstration. Et puis, même s’il reste des bugs, c’est bien de les connaître pour montrer qu’ils connaissent leur produit.
Pour ce qui est de la MMU, j’ai moi aussi suivi le thread effacé par Gunnar. Ce que j’ai compris, c’est qu’elle est différente du 060 et qu’elle reste encore au labo. Visiblement, elle n’est pas encore réellement bêta testée. Donc, parler de linux, c’est mettre la charrue avant les bœufs alors qu’il existe une avalanche de nouveautés plus prioritaires à perfectionner.
Personnellement, j’utilise continuellement la mmu sur mon Amiga. On a beau être rigoureux sur notre façon de coder, on n’est pas à l’abri de quelques bugs très cons. Genre une variable « pas » ou « mal » initialisée. Une mauvaise interprétation des autodocs sur la façon de scanner une structures (par exemple les listes chaînées amiga), d’autres types d’erreurs complexes.
@amigaouf
Gunnar a parlé mainte et mainte fois de la mmu du 68080. Elle est clairement une évolution de la mmu des 68k. Le fait qu’elle ne soit pas compatible avec les 040/060 est tout a fait dans l’esprit Motorola qui avait déjà fait sauter la compatibilité entre le 030 et le 040 pour des raisons du même ordre qu’actuellement.Sinon, il l’a dernièrement re-souligné, sa mmu permet maintenant de protéger une zone mémoire contre l’exécution de code. J’avais aussi lu un truc concernant une mmu compatible avec les dma. Pour ce point, j’attends des précisions.
Enfin, Gunnar peut être au courant de ce qui se dit ici car il y a des francophones qui bossent dans la Team. Si des questions pertinentes sont posées publiquement, elles peuvent arriver aux oreilles des concepteurs. Mais je ne dis pas que c’est systématique car, actuellement, ils ont d’autres chats à fouetter.
Mod La team est focus sur l’amiga32. (…) ils sont short pour être prêt le jour J
C’est clair.
Des bugs sont potentiellement encore cachés. Ça ferait tâche pour une première démonstration.
C’est tout le principe de préparer les évènements. Dans la vie réele aucun produit même fini n’est exempt de bug et pourtant ils sont montrés. Le but des préparations de demo(nstration)s est de bien baliser ce qu’on peut faire et ne pas faire avec le proto qui s’apprète à ête montré.
De toute façon dans mon boulot on considère qu’un produit n’a plus de bugs que le jour où plus personne ne l’utilise. Donc oui il faut connaitre les bugs et savoir les éviter lors des démonstrations. J’espère qu’ils ne sont pas tombés sur un pb bien casse-c*uilles lié à une petite ammélioration de dernière minute au niveau de la MMU (le sujet qui fâche Gunnar en ce moment). Le mieux est l’ennemi du bien, ou comme on dit au taf: on ne répare pas un truc qui marche!
Samuel.
Amiga A500 + GVP530 (8Mo/fpu/mmu/scsi) - en panne 🙁
A500 (+ 1Mo PPS), A1200 (Blizzard-IV/fpu/64Mo)
A500 Vampire V2+ ^8^ 🙂
(mais aussi TO8, TO8D, TO9. Groupe PULS.)@amigaouf
Oui, Guibrush a lâché son compte. Cela ne veut pas dire qu’il ne zieute pas ici de temps en temps. Idem pour Tuko.Et il nous reste encore un Highlander: Flype.
Lui, il suit encore et il répond de temps en temps. Je suppute qu’il n’a plus trop le temps d’écrire avec la sortie prochaine de la v4.
>quel base d info tu travails pour parler de la mmu du 68080 car perso j ai rien vu passer
Je répéte « je fais pas partie de la Team Apollo » mais je lis le forum Apollo presque tout les jours et une forme ou une autre de MMU spécifique au 68080 a été évoquée à plusieurs reprises. Par exemple:« Gunnar von Boehn
03 sept 2017>crow mohikan a écrit:
> tous les Amiga avec 68040/68060 intégré ont des CPU complets contenant une MMU fonctionnelle. C’est parce que Zorro III nécessite un mappage MMU de l’espace mémoire d’entrée/sortie.Merci pour le bon exemple.
C’est un autre exemple de quelque chose, qui est résolu sur 68080 automatiquement.Le 68080 possède également une MMU en interne.
Et pendant la mise sous tension, le réglage MMU du 68080 est automatiquement configuré correctement. »D’autre part plusieurs ont bien vu passer un message (sur Linux et aujourd’hui disparu) comme quoi « les specs de la MMU du 68080 était pas publique et que donc les modifs du noyau Linux 68k pour le rendre compatible 68080 étaient impossibles donc que Linux était hors-sujet »
A noter que Gunnar entretient souvent un flou entre le 68080 (qui aurait plein de fonctionnalités théoriques) et son implémentation actuelle dans le core fpga de la Vampire (qui n’a pas encore implémenté toutes ses fonctionnalités)
>je lis avec attention […] je sais que lui est codeur
Mais je peut dire des conneries aussi je suis pas infaillible ;-P>Donc oui il faut connaitre les bugs et savoir les éviter lors des démonstrations.
C’est tellement vrai 🙂
Idem quand j’organise des visites naturalistes j’évite aussi les plantes dont j’ignore le nomAlain
>j’ai l’impression que tu parlais simplement de la mauvaise utilisation par un utilisateur de fonctions mises à dispo
[desolé du hors-sujet]
Oui voici le code utilisateur de Maldita Castilla que recevais mon émulateur GMAPGML_instance_destroy detruit l’objet courant (cad ici obj_player désigné par Self)
Pourtant on a juste après Self->alarm[1]=-1;Cad que si je fais ce qui est pourtant prévu dans Game Maker alors je détruit obj_player alors Self accède à n’importe quoi = crash
Comme quoi un bon programme doit aussi savoir résister aux erreurs de l’utilisateur 🙂
——————————————————–
void gml_Object_obj_player_Alarm_1(struct GM_Game *G)
{if((Global->time > 1))
{
Global->time=(Global->time – 1);
Self->alarm[1]=150;
}
else
{
LONG result0=GML_instance_create(G,Self->x,Self->y,3);Self->nnn=result0;
Self->nnn->text=’TIME OUT!’;
GML_instance_destroy(G);Global->time=0;
Self->alarm[1]=-1;
}
if((Global->time < 10))
{
GML_audio_stop_sound(G,9);GML_audio_play_sound(G,9,10,0);
}
}
Voici le message de Gunnar retrouvé en cache et traduit
[Tout devient clair par de bons arguments. Même si le flou si on parle de 68080/Vampire reste]« Gunnar von Boehn
09 oct 2017 14:16>Kolbjørn Barmen a écrit:
>Le noyau prévu pour la V2 a t-il déjà, ou aura-t-il la MMU 68080?
> Est-il possible pour toute personne s’y intéressant d’utiliser cette MMU, sans avoir à passer par vous d’abord ?Le MMU est caché et n’est pas accessible pour vous.
Techniquement, c’est pour aujourd’hui la seule solution raisonnable.
Le MMU 68080 est par conception différente des précédentes MMU 68K.
Le 68080 dispose non seulement de 1 bus – mais de 2 bus et de 2 contrôleurs de mémoire. Donc une partie du travail de la MMU est de définir quelle page est sur quel bus.
En outre, le 68080 n’est pas un processeur 32 bits mais un processeur 64 bits.
Et 68080 prend en charge plus de « flags » de protection. Par exemple, on peut protéger non seulement en READ, WRITE – mais aussi protection contre l’ EXECUTION.
Aussi est nouveau que le 68080 peut contrôler le comportement du mode « burst ».
Il est donc clair que ces nouvelles fonctionnalités ne peuvent être « exposée » sur une même interface que par exemple une ancienne MMU 68030.
Si nous voulions « exposer » le MMU, votre ancien logiciel ne serait pas en mesure de le programmer correctement – et vous risqueriez de bloquer ou de perdre des données.
Comme nous protégeons les autres de cela – la MMU est aujourd’hui privée. »et aussi
« Nixus Minimax
09 Oct 2017 18:14>Kolbjørn Barmen a écrit:
> Cela implique-t-il également que le MMU est déjà utilisé par le firmware fourni avec les cartes Vampire?Comment pensez-vous que les cartes Vampire d’Amiga « mappent » de chipmem à la Vampire fastmem ou mappent les adresses des registre hardwares vers l’extérieur (custom chips Amiga) ou en internes ( FPGA), Ouvrez les yeux ! »
- Le sujet ‘Infos sur la Vampire’ est fermé à de nouvelles réponses.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire
