Martial Demolins (./29) :
Tu vas faire quelque chose pour la taille des fontes des différentes fenêtres (pour que le débogueur tienne plus sur du A0) ?
Kevin Kofler (./32) :
Il y a plusieurs erreurs dans les améliorations du désassembleur:
* Le correctif pour MOVEQ (rev 2666) n'est pas bon. Justement, un move #n peut être autre chose qu'un moveq, c'est pour ça qu'on te demande de distinguer! Il faut faire ça à l'intérieur du désassembleur.
* Je ne suis pas sûr pour les *I (rev 2667) non plus. Un add #imm est-il toujours un addi?
* rev 2668: là, tu as changé par exemple st en sra, ça ne va pas, il faut faire un cas particulier pour bt. Changer dbt en dbra n'est pas correct non plus, parce que dbra veut dire dbf.
Je suis aussi contre ton copier-coller du désassembleur de UAE. Commençons par dire que j'ai fait beaucoup de merges, y compris pas mal de merges de UAE dans TiEmu, donc je sais de quoi je parle. Le copier-coller est à peu près la pire des méthodes en ce qui concerne les merges! Ça veut dire effectivement que ce code n'est plus mergeable, et donc qu'on ne profite pas des nouveautés de UAE, de plus, si une interface interne de UAE change, il faudra porter le désassembleur à la main. Donc je préfèrerais que tu revertes le copier-coller de la révision 2672 et que tu fasses tes modifications à l'intérieur des sources de UAE. Quelques règles pour faciliter les merges (qui m'ont bien servi sur mes projets qui ont de nombreux patches, notamment le GCC de TIGCC):
* ne pas faire des modifications qui ne changent rien au fonctionnement, en particulier:
- ne pas toucher à l'indentation (et autre formatage)! D'ailleurs, ne pas toucher à l'indentation même si on rajoute ou supprime des niveaux de profondeur (par exemple un if de plus ou de moins), il vaut mieux un bloc mal indenté que des diffs inutiles sur chaque ligne.
- ne pas rajouter/supprimer/corriger des commentaires
- ne pas faire des "nettoyages" dans le code qui n'est pas à toi, il vaut mieux du code sale que des diffs inutiles
* si on veut supprimer de grosses parties du code, utiliser des #if 0 plutôt que d'effacer de gros blocs qui risquent de changer dans l'un ou l'autre détail et donc de casser le merge (en revanche, pour quelques lignes, supprimer est mieux)
Avec ton copier-coller, tu es parti pour faire exactement le contraire (adapter l'indentation à ton système, faire des nettoyages, ...), et donc on ne pourra plus merger, donc je suis absolument contre.
D'ailleurs, j'ai fait pas mal de modifications sur le désassembleur de GDB aussi, je les ai bien faites à l'intérieur des sources de GDB!
D'ailleurs, au lieu de bidouiller à fond le désassembleur de UAE comme tu es en train de le faire là, ne serait-il pas mieux de faire marcher le désassembleur de GDB/libopcodes sans le reste de GDB pour la version sans GDB, donc d'utiliser le même désassembleur partout? Si tu regardes dasm-tigcc, j'y ai réussi à peu près, mais il faudrait adapter ça à TiEmu (le but de l'exercice étant de faire ça sans avoir une deuxième copie du code de désassemblage de GDB, pour les raisons décrites dans le message précédent).
roms (./34) :
J'ai fait un copier/coller pensant que çà _te_ simplifierait le merge.
Mais ça ne fait que compliquer les choses en réalité, donc il vaut mieux ne pas faire ça.Si tu penses qu'il vaut mieux modifier in-place alors pas de problème pour moi, je préfères cette solution qui 1) évite la duplication du code 2) me permet réellement de fixer le désassembleur (en particulier les addq/subq qui ne peuvent être fixés qu'en modifiant le fichier table68k et le générateur de CPU).
Le même désassembleur partout ? Celui qui utilise la syntaxe GDB ? Si c'est le cas, ce n'est pas ce qu'on me demande (syntaxe Motorola)...
). Je pourrais le modifier pour sortir le format VTI aussi, mais je n'ai pas envie de le faire, je veux une sortie consistente avec les outils de TIGCC. Mais je ne serais pas opposé à une option ("VTI format", "GNU as format").
Oui, c'est mieux de modifier in-place, et vas-y pour les modifications à table68k et newcpu. En revanche, il faudra bien tester ça, pour ne pas casser l'émulateur en améliorant le désassembleur.
Il est déjà patché pour sortir une sortie en la syntaxe Motorola de GNU as. A la base, il sort de la syntaxe MIT. Je pourrais le modifier pour sortir le format VTI aussi, mais je n'ai pas envie de le faire, je veux une sortie consistente avec les outils de TIGCC. Mais je ne serais pas opposé à une option ("VTI format", "GNU as format").
Martial Demolins (./29) :
Tu vas faire quelque chose pour la taille des fontes des différentes fenêtres (pour que le débogueur tienne plus sur du A0) ?
Martial Demolins (./38) :
tu pooooooooooooootr !!!!!!
roms (./39) :
J'espère qu'il y a pas trop d'étrangers sur le forum parce que les pauvres, je les plains !
("Tu poutres", c'est-à-dire "you rule".) Cela dit, c'est vrai que ce genre de slang n'est pas toujours évident à comprendre. 
roms (./1) :
- c'est un peu dommage de pas pouvoir distinguer move.l de moveq, idem pour addq/subq
- il vaudrait mieux mettre la constante avant le registre, c'est mieux d'avoir lea ($42,a3),a3 pour voir du premier coup d'oeil que a3 et a3 c'est bien le même registre
- (a3,d0.l*1) : le *1 ne sert à rien, surtout sur 68000
- VTI utilise lea (-$c,a3),a3 au lieu de lea ($fff4,a3),a3, c'est plus lisible
- il y a "trap .l" au lieu de "trap #$C"
- rts.l
- il y a "bt<tab>.b" au lieu de "bt.b<tab>" (et sinon bra serait plus joli que bt)
- movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI
roms (./42) :
Ce qui va être fait (effectivement, çà sucks grave):
- movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI
Je ne comprends pas pourquoi vous utilisez la version sans GDB si vous déboguez!
J'ai énormément de trucs à faire déjà! Ne penses-tu pas que je devrais plutôt utiliser mon temps sur les bogues critiques comme les infos de débogage relogées à la mauvaise adresse pour les programmes kernel?
movem.l #$masque_incompréhensible, il vaudrait mieux les registres comme dans VTI
Martial Demolins (./51) :
VTI propose une simple case à cocher. Il est vrai que je ne me rends pas compte de ce que ça engendre comme code au niveau de TiEmu. Mais s'il est déjà capable de gérer les deux possibilités suivant le langage débogué, la majorité du code permettant de le faire est déjà en place, non?
Kevin Kofler (./55) :
Je ne nie pas que les modifications de Romain sont utiles, mais ils ont besoin de plus de tests avant de finir sur CalcForge.
roms (./57) :
J'ai décidé d'accepter la proposition de reprendre la maintenance des paquets Debian. Ces paquets n'étaient plus mis à jour depuis longtemps et ils étaient sur le point d'être supprimés.
