MulTI - Page 2

ben il garde l'assembleur z80 original, et en cas de branchement indirect ou de code automodifiant il utilise un interpréteur au lieu de lancer le code traduit ^^

Ok merci ^^
Sinon on pourrait éventuellement imaginer un système de cache pour le code qui devrait être traduit à la volée lors des branchements indirects: x lignes de y octets (de code original). Lorsqu'on fait appel à un branchement on vérifierait s'il est déjà en cache et on l'utiliserait, sinon on recompile cette partie...
Après faut bien sûr optimiser le lookup sur le cache...
En fait là où je bloque surtout c'est dans la gestion des trucs vraiment spéciaux, du style les timers qui sont déclenchés après X cycles, ou encore les HBLANK.
Et je parle même pas des DMA: lorsqu'on écrit à une certaine adresse mémoire, ça bloque le proço et lance une copie mémoire... va détecter ça dans des cas comme ceci (pseudo code):

    ; r0 => 0x4000000 (IORAM)
maRoutine:
    add r0, r0, #0xDC       ; 0x40000DC => DMA control register
    or [r0], #0x80000000    ; DMA enable bit

Y'aurait-il une solution dans ce cas (à part vérifier tous les adressages indirects)?

C'est quoi ton proc là ?

Sinon le système de cache, pas comme si j'y avais pas pensé, mais sur TI on est un peu short en mémoire et en temps processeur

C'est du pseudo-code qui représente aucun proço... pour le DMA j'ai pris la GBA en exemple, mais il doit y avoir pareil sur GB/DMG j'imagine, non?

Y'a bien du DMA dans la GB, mais pour moi ça s'inclue dans l'émulation des I/O memory mapped registers, tu connais l'adresse de ces registres et tu dois de toutes façons contrôler où tu écris en mémoire, quel que soit le mode d'écriture...
Et petite note, justement le transfert DMA ne bloque pas le processeur, et c'est sa raison d'être.

Tiens, amusant Ca veut dire que les deux peuvent accéder à la mémoire en même temps
C'est pas le cas sur GBA...
Mais bon contrôler où tu lis/écris ça ralentit de tte façon à mort (le proço de la GB c'est quoi, 1 MIPS environ? A émuler sur un 68k qui en fait 3? Hm )

Nan ils ne peuvent pas le faire en même temps, la DMA est justement basée sur le fait que le proc passe une grande partie de son temps à faire des opérations sur ses registres, sur son cache, voir dans d'autres segments de la mémoire et profite de ce temps pour occuper le bus. Un contrôleur d'accès à la mémoire gère les accès. A la fin d'un transfert DMA, le processeur reçoit une interruption pour l'en avertir, et il peut alors accéder aux données transférées (que ce soit pour réutiliser le buffer d'origine ou pour traiter le buffer d'arrivée).
De quoi qui n'est pas le cas ?
Tu n'as pas le choix, vu que certaines adresses ne sont pas de la mémoire mes des registres aux comportements spéciaux. Mais sur GB, il y a une instruction particulière pour lire/écrire aux adresses des ports, ce qui limite les problèmes (enfin à vérifier).
Et tu comprends pourquoi on n'a pas encore d'ému gameboy qui tourne à 100% de la vitesse

Brunni :
Ok merci ^^Sinon on pourrait éventuellement imaginer un système de cache pour le code qui devrait être traduit à la volée lors des branchements indirects: x lignes de y octets (de code original). Lorsqu'on fait appel à un branchement on vérifierait s'il est déjà en cache et on l'utiliserait, sinon on recompile cette partie...

Oui, évidemment c'est ce qu'il faudrait faire si le compilateur était disponible on-calc et ne prenait pas trop de place ^^ (mais de toute façon c'est pas clair qu'une interprétation bête et méchante dans ces qques cas aurait un impact significatif sur la vitesse...)

En fait là où je bloque surtout c'est dans la gestion des trucs vraiment spéciaux, du style les timers qui sont déclenchés après X cycles, ou encore les HBLANK.
Et je parle même pas des DMA: lorsqu'on écrit à une certaine adresse mémoire, ça bloque le proço et lance une copie mémoire... va détecter ça dans des cas comme ceci (pseudo code):

    ; r0 => 0x4000000 (IORAM)
maRoutine:
    add r0, r0, #0xDC       ; 0x40000DC => DMA control register
    or [r0], #0x80000000    ; DMA enable bit

Y'aurait-il une solution dans ce cas (à part vérifier tous les adressages indirects)?

Ben c'est le vrai problème, à savoir que si on a aucune information statique sur où pointe quoi, un accès à la mémoire sur <insérez ici votre plateforme favorite> doit être bourré de vérifications ^^ (et c'est assez probable que ces vérifications prendront 90% du temps d'exécution )
A partir de là il y a plusieurs possibilités :
[ul][li] faire une analyse statique de pointeurs fine, et comme je l'ai dit dans ./7 c'est sans doute extrêmement difficile sachant que les jeux doivent être écrits de façon gore et sont potentiellement buggés. Bref si ça marche, c'est l'idéal niveau performance, mais ça risque de demander plein de boulot pour chaque jeu...
[li] avoir un compilateur dynamique de code qui détecte où pointent les données, fait des statiques dessus et regénère les routines si un bout de code peut être réécrit pour supprimer des tests manifestement inutiles. On doit pouvoir faire des trucs vraiment sympas avec ça, mais ça doit être assez délicat à bien faire...[/ul]

Ximoon :
Nan ils ne peuvent pas le faire en même temps, la DMA est justement basée sur le fait que le proc passe une grande partie de son temps à faire des opérations sur ses registres, sur son cache, voir dans d'autres segments de la mémoire et profite de ce temps pour occuper le bus.

Le proc de la GB a un cache ?

Pollux :
faire une analyse statique de pointeurs fine, et comme je l'ai dit dans ./7 c'est sans doute extrêmement difficile sachant que les jeux doivent être écrits de façon gore et sont potentiellement buggés. Bref si ça marche, c'est l'idéal niveau performance, mais ça risque de demander plein de boulot pour chaque jeu...

Je ne pense pas que les jeux soient vraiment codés de façon si crade que ça, comme déjà dit L'avenir nous le dira

Pollux :
avoir un compilateur dynamique de code qui détecte où pointent les données, fait des statiques dessus et regénère les routines si un bout de code peut être réécrit pour supprimer des tests manifestement inutiles. On doit pouvoir faire des trucs vraiment sympas avec ça, mais ça doit être assez délicat à bien faire...

Et surtout ça va prendre plein de mémoire et de temps processeur, et là on est assez limités

Pollux :

Ximoon :
Nan ils ne peuvent pas le faire en même temps, la DMA est justement basée sur le fait que le proc passe une grande partie de son temps à faire des opérations sur ses registres, sur son cache, voir dans d'autres segments de la mémoire et profite de ce temps pour occuper le bus.

Le proc de la GB a un cache ?

Non, mais je parlais de manière générale. Ceci dit, le DMA de la GB sert à transférer des sprites vers la mémoire du contrôleur vidéo, et des contraintes d'accès à la mémoire font que dans les faits, on doit copier du code en RAM et l'exécuter pendant que les sprites sont lus en ROM. Ca me semble assez foireux comme système en fait.

Ximoon
:

Pollux :
faire une analyse statique de pointeurs fine, et comme je l'ai dit dans ./7 c'est sans doute extrêmement difficile sachant que les jeux doivent être écrits de façon gore et sont potentiellement buggés. Bref si ça marche, c'est l'idéal niveau performance, mais ça risque de demander plein de boulot pour chaque jeu...

Je ne pense pas que les jeux soient vraiment codés de façon si crade que ça, comme déjà dit

Je ne parle pas d'exécution de code illégal, je parle d'avoir des structures de données ou des entiers qui peuvent déborder de leur valeur "normale" dans des conditions anormales...

Et puis quand bien même ça serait pas le cas et que la plupart des jeux soient prouvables avec un theorem prover (mais je donnerais ma main à couper que ce n'est pas le cas), le faire de manière automatique risque d'être délicat et il y aura probablement des adaptations manuelles à telle structure de donnée bizarre à faire, donc je maintiens mon "plein de boulot pour chaque jeu"

Pollux :
avoir un compilateur dynamique de code qui détecte où pointent les données, fait des statiques dessus et regénère les routines si un bout de code peut être réécrit pour supprimer des tests manifestement inutiles. On doit pouvoir faire des trucs vraiment sympas avec ça, mais ça doit être assez délicat à bien faire...

Et surtout ça va prendre plein de mémoire et de temps processeur, et là on est assez limités

Oui, la quantité de RAM dispo serait vraiment un facteur limitant ^^

Ceci dit le coup de l'exécution de code en RAM (donc potentiellement auto modifiable) rend, en première analyse, l'utilisation d'un interprêteur obligatoire (mais je pense également que les appels nécessitant l'interprêteur sont rares et que du code précompilé représenterait une part très importante du code exécuté)


edit: sauf à faire un programme vraiment compliqué pour déterminer tous les codes possibles exécutables en RAM

Ok je vois. C'est effectivement foireux mais ça permet d'en tirer le max si t'y arrives. Sur GBA le processeur est tout simplement déclenché pendant que le DMA est actif, et rallumé à la fin. L'avantage c'est que c'est transparent pour toi et qu'un DMA se déroule comme un memcpy et que ça économise un peu d'énergie, mais c'est du temps de processing perdu
Sinon merci des explications...
[Edit] Pour le truc de la RAM oui j'avais pas pensé, c'est encore pire du coup, surtout sur GBA où certains mettent leur code entier en IWRAM parce qu'elle est plus rapide (et c'est la même mémoire qu'occupe la pile, et l'iheap...) :/

Ximoon>

Mais je comprends pas, si tu veux faire une analyse statique de pointeurs qui te serve à quoi que ce soit ça implique que tu connaisses *tout* ton code, *tout* l'état de la mémoire, etc..., donc c'est complètement incompatible avec le fait de rajouter un interpréteur qui pourra modifier arbitrairement toute la mémoire Je sais pas ce que tu as compris quand j'ai dis "analyse statique de pointeurs fine", mais c'était de ça que je parlais ^^

J'ai dû mal comprendre ce que tu entends par "analyse de pointeurs fine"

OK, ben en gros si tu veux pouvoir éliminer la plupart des vérifications coûteuses "est-ce que cette adresse pointe en RAM, en ROM, ou dans un port i/o ?", c'est très délicat parce qu'étant donné que les pointeurs risquent d'être stockés en RAM à un moment ou à un autre, pour pouvoir être sûr qu'un pointeur stocké en RAM vers un port i/o pointera toujours vers un port i/o à sa prochaine lecture, il faut être capable de prouver qu'aucune des écritures en RAM effectuée avant la lecture de ton pointeur ne modifiera ton pointeur : bref ça veut dire qu'il faut vraiment avoir une vision d'ensemble du programme, que l'analyseur doit "comprendre" comment fonctionnent toutes les structures de données du programme, et qu'en plus un bug obscur dans un coin de la ROM casserait tout s'il n'est pas corrigé (si un bug écrit à un moment donné à une adresse aléatoire, l'analyseur ne peut plus rien prouver sur le contenu de la mémoire après cette écriture...)

Bref, c'est pas vraiment envisageable même si ça serait l'idéal niveau performance. Du coup oui, on est un peu obligé de faire des heuristiques "ça je traduis en code natif, ça je crois pas que ça soit exécutable mais j'interpréterai si ça l'est, etc"

Hmmm oui c'est la conclusion à laquelle j'étais arrivé, sinon je pense qu'on pourrait aller aussi vite à recoder tous les jeux GB de A à Z plutôt que de faire ton analyseur et d'investir dans un ou deux supercalculateurs