Logicielsmoto.com
http://www.logicielsmoto.com/phpBB/

C6809 version 0.83, alors ?
http://www.logicielsmoto.com/phpBB/viewtopic.php?f=10&t=362
Page 2 sur 3

Auteur:  jb_jb_fr [ 11 Avr 2019, 11:49 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Samuel Devulder a écrit:
...test la distance entre *+2 et lbl et si c'est entre -128 et 127 fait un BRA label et JMP label sinon


Attention : BRA est relatif, alors JMP est absolue
Pourquoi ne pas choisir entre BRA et LBRA ?
Ainsi, tu auras du code entièrement relogeable. :)

Depuis que je fais de l'OS9, j'ai banni tout déplacement absolue, et je trouve cela tres bien, surtout que le 6809 le permet.

Jacques

Auteur:  Samuel Devulder [ 11 Avr 2019, 12:12 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

1) Il y a une autre macro pour les versions en adressage relatif (et les autres tests en général). Je ne l'ai pas détaillée, mais le problème est similaire.

2) LBRA est plus gros que JMP en mode direct. En outre, LBRA est aussi plus lent que JMP. Bref LBRA c'est vraiment quiant on peut pas faire autrement (code impérativement relogeable).

3) je ne fais quasiment pas de programmes relogeables. Je privilégie en 1) la vitesse et en 2) la compacité. Donc la macro avait ce but en tête.

J'ai un contournement "tempooraire" pour la macro: il faut ajouter un NOP (inutilisé) après le BRA, ainsi les 2 branches du IF font 3 octets (sauf si l'optimisation de l'assembleur décide de faire passer JMP en mode direct, mais c'est un autre sujet) et du coup les adresses sont inchangées, et donc toujours bonnes. Mais dans le cas des branchements conditionnels, ce NOP ajoute 2 cycles ce qui rend les branchements courts presque aussi lents que les longs. C'est pas génial.

Je truc ultime serait en fait que cc6809 (en mode "optim") soit à même d'optimiser les branchments relatifs longs en courts lorsque c'est possible (en recalculant toutes les adresses et offsets correctement dans la foulée.)

Auteur:  Prehisto [ 11 Avr 2019, 14:21 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Il y a peut-être un moyen de contourner le problème en mettant L1 et L0 en SET plutôt qu'en EQU.

Auteur:  Samuel Devulder [ 11 Avr 2019, 14:56 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Avec des SET c'est encore différent:
Code:
        org     $9000

      
JP    MACRO
      echo saut en $\0
      IFEQ    (\0-*-2)&$FF80
      bra     \0  ; branchements positifs
      ELSE
      IFEQ    (*+1-\0)&$FF80
      bra     \0  ; branchements negatifs
      ELSE
      jmp     \0
      ENDC
      ENDC
      ENDM
      
      JP      L1
L0     SET     *
      RMB      126,0
L1     SET     *
      JP      L0
      echo   L0=$L0
      echo   L1=$L1
    
     END
=====================================================
$ make
tools/c6809.exe -c -bh -am -oOP fpu.ass `echo fpu.BIN|tr a-z A-Z`
Macro Pass
Pass1
Pass2
saut en $9081
saut en $9002
L0=$9002
L1=$9080

000000 Total Errors


La valeur de L0 est bonne au niveau de la macro (saut en $9002), celle de L1 est fausse (saut en $9081 au lieu de $9080).

Donc pour le saut "positif" ca marche pas, par contre le saut à rebours c'est OK (avant aucun des deux n'était bon.) Je me demande si je faisais un "BRA \0-1" (ie soustrait 1) dans le cas d'un saut positif ca marcherait dans 100% des cas (mais ca serait moche car ca serait du code ASM spécifique à la version buggée de cc6809).

Auteur:  Prehisto [ 11 Avr 2019, 15:33 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Surtout que l'assemblage fonctionne très bien sur le Thomson avec des EQU, donc je ne vois pas pourquoi ça ne fonctionne pas ici. J'ai dû oublier quelque chose.

Auteur:  Samuel Devulder [ 11 Avr 2019, 15:41 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

En fait l'astuce du "-1" ne marche pas, ou du moins ca n'est pas localisé au sein de la macro. C'est localisé partout où L1 est présent. Si on met un JMP L1 à une adresse fixe (ORG $9100), et bien il saute en $9081 et pas $9080. Il faudrait donc faire plutôt "L1 SET *-1", c'est à dire mettre le -1 dans le SET lui même. Mais alors un saut relatif en L1 depuis une adresse plus haute ne sautera pas à la bone addresse.

Bref: le "-1" ne marche pas dans le cas général, vu que c'est tous les labels après L0 qui sont décalé dans un sens pour les sauts croissants, mais pas décalés pour les sauts décroissants. Il faut oublier ce contournement. :cry:

Auteur:  gilles [ 11 Avr 2019, 15:46 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

sinon tu peux avoir une version statique qui ne fait que détecter le dépassement et sortir la compilation en erreur. Je ne sais pas si c6809 le fait d'ailleurs.
Quand tu tombes dessus tu modifie ton source pour faire un saut long.
Je vois l'interet de ce que tu veux faire mais je me demande si ca ne risque pas d'osciller entre plusieurs valeur et ne jamais terminer si un systeme d'invalidation de condition de macro est pris en compte.
perso je sortirai en erreur de compilation si la condition d'une macro n'est totalement définie au moment où elle est interprétée. ca ne t'avancera à rien pour ce que tu veux faire mais en se placant du coté de "l'éditeur" c'est une option saine :) mais du coup oui on peut imaginer des optims globales dans le produit

Auteur:  Samuel Devulder [ 11 Avr 2019, 15:56 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Oui les oscillations sont possibles, mais c'est vraiment parce qu'on l'a cherché (le code normal n'en aura pas). Par contre le nb de passes avant stabilisation n'est pas garanti non plus. Ce qui fait qu'une boucle "finie" n'est pas une stratégie suffisante.

Pour le moment je vais faire des sauts classiques et puis tant pis. Oui CC6809 grogne avec un "Out of range" quand l'addresse pointée n'est pas accessible aux sauts courts. Ca aide, mais lors de la mise au point et du déplacement de code, je suis sans arret à remplacer les LBEQ par des BEQ et vice-versa, ce qui m'avait motivé à faire la macro JP pour ne pas avoir a repasser après des centaines de sauts dans tous les sens (oui c'est pour du code algorithmique un peu compliqué à écrire en ASM.)

Le message de jb_jb_fr m'a fait réalisé que LBRA n'est pas aussi mauvais que je le croyais, en fait je devrais écrire! n'est pas aussi mauvais que les autres sauts-longs conditionnels. Il doit être si fréquent dans les ROMs que les ingénieurs motorola ont fait en sorte qu'il n'ait pas besoin du prefix $10, et donc est 1 octet et 1 cycle plus court que les autres sauts longs. Je n'avais pas réalisé cela jusqu'ici ;)

Auteur:  gilles [ 11 Avr 2019, 16:36 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

y'a bien un algo possible je suppose
du genre si dans une condition on a un label pas encore défini alors on le marque non défini et on passe à la suite.
si en arrivant au label on a tout défini alors on choisit en tenant compte en tenant compte de la taille dans les 2 branches, si la condition reste vraie dans les 2 branches le choix est définitif, sinon on choisit le plus long pour l'évaluation de condition (ce n'est pas utile dans notre cas mais j'imagine qu'on peut trouver un cas tres tordu ou le code le plus long est le plus rapide (genre dans un cas un mul et dans l'autre des shifts)) mais on laisse le label non défini.
je n'ai pas du tout regardé comment c6809 fait son traitement, j'imagine juste comment je ferai un truc comme ca.

pour autant d'un point de vue concept je trouve qu'utiliser une adresse de label comme condition de macro c'est mal :)

Auteur:  Samuel Devulder [ 11 Avr 2019, 17:09 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Conceptuellement, tu penses qu'il faudrait mettre uniquement des constantes dans les IF pour qu'ils soient toujours évalués à une valeur fixe indépendamment du contexte je suppose.

Ca se défend en effet. Mais exit les pseudo-instructions intelligentes style le JPIF (JUMP si, extension du JP avec les conditions) qui choisit de lui même entre un saut long et un saut court.

A noter à propos des cycles dans les evaluations de IFs interdépendants, dans le choix saut-long/saut-court, c'est qu'il y a une absence de point fixe. Or il y a un point fixe évident qui est: tous les sauts sonts longs par défaut. A partir de là les optims ne font que nécéssairement réduire srtictement la taille si on traite les IFs un à un du haut vers le bas du source, ce qui me semble être un bon invariant pour prouver que l'algorithme converge finalement vers un minimum local. Ce n'est pas forcément le minimum absolu, mais il a la propriété d'être unique et donc stable.

@Prehisto: tu dis que ca marche sur assembleur v3? C'est surprenant car je le pensais moins évolué que cc6809 (16ko de binaires 6809 vs 160ko de C-ansi ;) ).

Auteur:  Prehisto [ 11 Avr 2019, 17:17 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Samuel Devulder a écrit:
@Prehisto: tu dis que ca marche sur assembleur v3?

Ben oui. Tu devrais essayer et me dire ce que tu en penses.

Auteur:  Samuel Devulder [ 11 Avr 2019, 17:29 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

Coup de bol, ou meilleur algo?
Fichier(s) joint(s):
Image1.png
Image1.png [ 9.69 Kio | Vu 315 fois ]
Fichier(s) joint(s):
Image2.png
Image2.png [ 10.17 Kio | Vu 315 fois ]

Je penche pour le coup de bol, car si le mets le RMB à 128, ca plante grave avec des "Mult Symbol" sortis de nulle-part
Fichier(s) joint(s):
Image3.png
Image3.png [ 10.71 Kio | Vu 315 fois ]

Auteur:  gilles [ 11 Avr 2019, 17:37 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

je sais bien que c'est pratique, d'ailleurs certain assembleurs le font directement sans te poser la question, le BRA peut devenir LBRA si l'offset est hors plage.
Ce n'est pas génant si c'est une passe spécifique qui doit forcement intervenir après l'interprétation des macros... et c'est là que le fait de pouvoir utiliser un label non défini dans une condition de macro crée une incohérence. perso je préfère une erreur à la compilation (et de préférence un code d'erreur qui a du sens et qui me montre le truc qui ne lui plait pas).

Auteur:  Prehisto [ 11 Avr 2019, 17:44 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

En fait, je pense qu'il doit mettre la valeur de sortie à $0000 lors d'une erreur d'évaluateur dans MacroAssembler alors qu'il ne le fait pas dans c6809. c6809 récupère une valeur non nulle.

Le résultat du IF étant égal à $0000 pour MacroAssembler, il va choisir d'office un BEQ. Donc les adresses de L0 et L1 seront exactes à la deuxième passe.

Auteur:  Samuel Devulder [ 11 Avr 2019, 17:44 ]
Sujet du message:  Re: C6809 version 0.83, alors ?

(suite)...A moins que ce "Mult Symbol" soit une manifestation des mutli-passes de l'algo quand il y a un changement des adresses entre deux passes (le symbole est défini en double avec des adresses distinctes.) Cela est confirmé par le fait que si je passe les labels en SET, ca ne plante plus et l'algo stoppe sur le point fixe Maximal.
Fichier(s) joint(s):
Image4.png
Image4.png [ 10.8 Kio | Vu 314 fois ]

Mais bon dans tous les cas, le binaire généré est bon, même si sous-optimal. Donc +1 pour assembleur v3 et 0 pour cc6809.

@Gilles, oui ca serait bien que l'assembleur puisse faire ce changement lui même. Mais il faut aussi la possiblité de bloquer cette optim pour une instruction donnée parce qu'on veut un timing précis. D'où l'idée d'une pseudo instruction comme le CALL du MO5. Pseudo instruction que je tente de faire avec une macro.

Page 2 sur 3 Heures au format UTC + 1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/