Bon, je vais pas continuer à polluer le topic sur l'ARM7 éternellement, alors je vais poster ici.

J'ai commencé à porter l'ému du C++ vers le C. Finalement, c'est pas si difficile à faire
J'ai porté juste la partie "DSP" de l'émulateur, et ça compile impec sans warnings avec -Wall.
Reste la partie "SPC" à faire, et je pourrai tester sur ordi, avant de me lancer dans le port pour l'AICA.

Sinon, je viens de me rendre compte que mon gcc pour ARM est en 4.0.4 ; or sur cette page ils parlent d'un problème pour les versions supérieures à la version 3.0.4.
Mes problèmes d'exécution venaient peut-être de là ?
Est-ce que c'est corrigé avec la 4.4 ?

--Message edité par titemoo le 2009-06-10 17:57:08--

Alors pour ce qui est des problèmes de GCC Arm7, je peux pas te dire. J'ai eu tellement de problèmes que j'ai fini par faire un copier/coller du SDK du Live CD de L@Cible!!!

le kit de dev pour gba/nds/gp32 utilisait binutils 2.19 et gcc 4.3.2 au début de l'année.

Ah ok, donc y'a pas de raison que ça ne marche pas pour l'AICA.

Bon j'arrive a compiler tous les objets, mais impossible de faire l'édition des liens. J'ai que des erreurs du type "définition multiple". J'ai pas énormément de temps à y consacrer, malheureusement...

Quelques news :
J'ai réussi à porter l'émulateur du C++ vers le C, ça fonctionne impec sur PC
Prochaine étape, je porte ça sur l'AICA. Je suis pas trop optimiste concernant la vitesse cependant...

Eh ben bon courage, tu as des vacances? Tu vas pouvoir y passer un peu de temps?
Moi, j'ai plus trop le temps, je retape ma vieille maison en attendant un heureux événement en octobre!

Ah, félicitations
J'ai pas trop le temps malheureusement, je pars en école d'ingénieur début septembre...

Ah ben tu auras du temps à ce moment-là, alors :-)

Bon je suis en train de tester une nouvelle approche là, je ne fais plus de l'émulation mais de la "traduction binaire"
En gros je n'ai pas un programme qui parse l'exécutable du SPC700, je réécris carrément ce programme en code ARM...
Évidemment c'est vraiment difficile, j'ai plein de problèmes divers, mais bon on verra bien où ça va me mener...

En gros, je réécris le programme du SPC700 en ARM, et je jump dessus après avoir préparé une interruption IRQ pour dans ~32 cycles (nombre de ticks par sample générée) : une fois interrompu, je récupère les valeurs des registres du DSP émulé modifiés par le SPC700 et je retranscris ça pour l'AICA par une pseudo-émulation du DSP (plutôt une couche de compatibilité). Puis, je reprogramme une interruption et je recommence...

Les avantages :
- C'est énormément plus rapide, vu que le code est exécuté à la vitesse du processeur et sans les inconvénients du dynarec (je peux utiliser les registres du processeur à ma guise), et il serait même plus rapide (à même fréquence du proc) grâce à la supériorité de l'ARM
- Si j'interromps toutes les 32 ticks, il me reste au moins 700 tours d'horloge utilisables pour l'émulation du DSP.
- Je peux décompresser les samples avant d'envoyer le tout à l'ARM (les samples sont stockées sous forme compressée dans les 32kio utilisables du SPC700).

Problèmes et inconvénients :
- BEAUCOUP plus difficile qu'une émulation standard. Je suis obligé de recréer un éxécutable sans assembleur, donc j'utilise des macros qui me créent un code binaire...
- Le système d'adressage du SPC700 est plutôt vieux et compliqué ("direct page")... Du coup certaines instructions simples comme par exemple une incrémentation "(dp)++" prennent plus de cycles avec l'ARM qu'avec le SPC700... C'est un problème en suspens, je pense que je vais le régler en doublant le nombre de cycles par sample pour l'ARM, donc passer de 32 à 64 cycles, ce qui serait deux fois plus lent mais qui me permettrait plus de libertés.
- Le temps nécessaire à la "traduction" : je ne sais pas du tout combien de temps le SH-4 mettrait à traduire 32kio de données...
- Une fois le programme chargé, la SNES émulée envoie des données à son proc son (nouveaux programmes, samples...). Il faudrait pouvoir traduire "en live" ces données, et commencer à les envoyer à l'ARM même si la SNES n'a pas fini d'émettre, histoire de gagner du temps (et de ne pas ralentir le reste). Seul problème, comme la taille de mes opcodes diffère il me serait impossible de connaître la nouvelle adresse d'un label que je n'ai pas encore rencontré...
Et imaginons que j'attende d'avoir traduit l'ensemble du programme avant de l'envoyer à l'ARM7, je suppose que cela créerait un décalage sonore probablement audible...

Bref ça fait beaucoup de points de suspension, mais comprenez que c'est quand même super intéressant, j'espère que j'aboutierai à quelque chose

--Message edité par titemoo le 2009-08-23 23:35:41--

Eh ben dis-donc, et après, tu dis que mon driver est complique ;-)
Ca a l'air sympa en tout cas. Par contre, je ne suis pas certain d'avoir tout compris.

Ah, mais j'ai pas dit que j'avais tout compris moi-même !! J'espère juste que ça va venir petit à petit

Bon c'est vraiment l'extase, plus j'avance et plus je me dis que je vais aboutir à quelque chose

J'ai une question cependant : j'ai une fonction qui prend deux "char" en paramètre, le deuxième étant un shift à appliquer au premier pour obtenir une pseudo-adresse 32 bits (pseudo adresse, car on aura toujours une précision de 8 bits) ; au début, j'ai utilisé deux #define pour ces deux valeurs, que le développeur doit définir.
Par exemple :
#define ADDR 0x3
#define SHIFT 0xA
pour obtenir une adresse globale égale à (0x3 << 0xA) soit 0xC00.

Ce que je voudrais, c'est pouvoir, à partir d'un #define GLOBAL = 0xC00, retrouver l'adresse 8 bits ADDR et le SHIFT, sans que la machine n'ait à les calculer, que ce soit préalablement fait par le compilateur, si possible sans les optimisations d'activées.

Des idées ?

#define GLOBAL (ADDR << SHIFT)
Ce sera calculé par le compilo.
Si c'est pas ça, je n'ai pas compris la question :-)
Sinon, à partir du GLOBAL, tu ne peux pas retrouver les 2 sans connaitre l'un des deux, à moins de faire du log base 2 ou ce genre de cochonneries.
Qu'est-ce que tu comptes faire exactement?

Citation :

Sinon, à partir du GLOBAL, tu ne peux pas retrouver les 2 sans connaitre l'un des deux, à moins de faire du log base 2 ou ce genre de cochonneries. Qu'est-ce que tu comptes faire exactement?

Ah, bah c'est ça que je voulais faire

Le probleme c'est qu'a partir d'un global donné, en général il y a plusieurs couples addr/shift possibles.

Ouep, mais j'en ai besoin d'un seul pour que ça fonctionne

Alors utilise SHIFT = 0 :-)

--Message edité par bouz le 2009-09-26 16:28:33--