Logicielsmoto.com http://www.logicielsmoto.com/phpBB/ |
|
C6809 version 0.83, alors ? http://www.logicielsmoto.com/phpBB/viewtopic.php?f=10&t=362 |
Page 3 sur 4 |
Auteur: | gilles [ 11 Avr 2019, 17:59 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
pour prouver que la méthode marche il faut aussi avoir un branchement court en avant et un en arrière dans le meme cas de test non? (idéalement il faudrait même formellement vérifier que toutes les variables évaluées sont correctes, ce qu'on doit pouvoir faire dans c6809, dans la cartouche asm c'est plus sportif) |
Auteur: | Samuel Devulder [ 16 Avr 2019, 14:46 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
En lisant une doc d'un autre assembleur 6809, j'ai vu qu'il y avait un IF de plus, à savoir IFP1 (et en fait aussi IFP2). Le contenu de ce If n'est évalué que pendant la passe 1 (la phase de macro-expansion). Avec ce type de IF, on pourrait peut-être se débrouiller dans le cas actuel. Y aurait-il une façon d'émuler cela avec c6809 ? (style une construction du macro processeur qui permette à une variable de valoir 0 en 1ere passe et autre chose sinon.) Autre truc assez pratique: dans certains assembleurs 6809 on peut ajouter NOEXPAND à la définition d'une macro. Cela a l'effet de masquer son expansion dans les lignes du fichier généré équivalent au "codes.lst" produit. Pour moi qui utilise pas mal les macro instructions, c'est vrai que d'avoir NEGD (la macro) au lieu de 3 lignes avec NEGA NEGB SBCA#0 (la version expandée de NEGD) rendrait le fichier codes.lst plus lisible. |
Auteur: | Prehisto [ 16 Avr 2019, 16:47 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Samuel Devulder a écrit: En lisant une doc d'un autre assembleur 6809, j'ai vu qu'il y avait un IF de plus, à savoir IFP1 (et en fait aussi IFP2). Le contenu de ce If n'est évalué que pendant la passe 1 (la phase de macro-expansion). Avec ce type de IF, on pourrait peut-être se débrouiller dans le cas actuel. Y aurait-il une façon d'émuler cela avec c6809 ? (style une construction du macro processeur qui permette à une variable de valoir 0 en 1ere passe et autre chose sinon.). Oui oui je suis dessus, et effectivement, il doit y avoir quelque chose comme ça J'ai déjà dû revoir toute ma routine pour l'enregistrement des symboles, et la faire réagir au plus proche de MACROASSEMBLER. |
Auteur: | Prehisto [ 16 Avr 2019, 17:22 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
En fait, il y a même des petites astuces. Par exemple, pour les SET et EQU, l'opérande est évaluée avant le label, et le label ne sera enregistré dans la table des symboles que si l'opérande a pu être définie (donc si elle ne comporte que des éléments qui ont pu être définis) ou qu'il s'agit de la dernière passe. Par exemple. |
Auteur: | Prehisto [ 17 Avr 2019, 22:27 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Pour tout dire, MACROASSEMBLER a quand même ses limites. Quand on fait par exemple: Code: Z5 EQU Z4 Z4 EQU Z3 Z3 EQU Z2 Z2 EQU Z1 Z1 EQU Z0 Z0 EQU 12 seuls Z1 et Z0 seront définis. Pour bien faire, il faudrait autant de passes que de EQU non encore définis. |
Auteur: | Samuel Devulder [ 17 Avr 2019, 23:15 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
En effet. Avec des SET il n'y a pas ce problème je suppose ? (le SET faisant toujours référence aux dernières valeurs) Pour tout dire j'utilise (massivement) ce style de construction avec mon dernier jeu de macros: Code: * define a stack (j'en dirais plus à ce sujet plus tard, mais pour teaser je dirais que cela me permet de faire des trucs tout nouveaux qui m'amusent beaucoup.)
DOSTCK MACRO DO9\0 set 0 DO8\0 set 0 DO7\0 set 0 DO6\0 set 0 DO5\0 set 0 DO4\0 set 0 DO3\0 set 0 DO2\0 set 0 DO1\0 set 0 DO0\0 set 0 ENDM * default stack DOSTCK * push value on to a stack DOPUSH MACRO IFNE DO9\1 STACK OVERFLOW ENDC DO9\1 set DO8\1 DO8\1 set DO7\1 DO7\1 set DO6\1 DO6\1 set DO5\1 DO5\1 set DO4\1 DO4\1 set DO3\1 DO3\1 set DO2\1 DO2\1 set DO1\1 DO1\1 set \0 ENDM * pop value out of a stack DOPOP MACRO IFEQ DO1\1 STACK UNDERFLOW ENDC DO1\1 set DO2\1 DO2\1 set DO3\1 DO3\1 set DO4\1 DO4\1 set DO5\1 DO5\1 set DO6\1 DO6\1 set DO7\1 DO7\1 set DO8\1 DO8\1 set DO9\1 DO9\1 set 0 ENDM |
Auteur: | Prehisto [ 18 Avr 2019, 06:48 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Samuel Devulder a écrit: En effet. Avec des SET il n'y a pas ce problème je suppose ? (le SET faisant toujours référence aux dernières valeurs) Même avec des SET, le problème est le même. |
Auteur: | Samuel Devulder [ 30 Avr 2019, 14:09 ] | ||
Sujet du message: | Re: C6809 version 0.83, alors ? | ||
Voici ci-joint des petites modifs que je me suis faite sur C6809 0.83 pour le rendre plus agréable à utiliser.
Le fichier c6809.c est dans le ZIP ci-joint avec son diff par rapport à la version officielle du site PULS (qui semble être passablement pas à jour au niveau des autres fix que j'ai trouvé en faisant le diff: utilisation de fstat, cycles de ORCC/ANDCC etc).
|
Auteur: | Prehisto [ 30 Avr 2019, 14:29 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Hé non, elle n'est pas à jour, parce que ça n'est plus celle sur laquelle je travaille, mais sur une version bien plus intéressante que je t'avais pourtant envoyée personnellement, si je me souviens bien, et que tu ne sembles pas utiliser pour autant. |
Auteur: | Samuel Devulder [ 30 Avr 2019, 14:41 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Humm il faut que je me replonge dans les archives mail alors. Je pense que je suis parti d'une de test versions interne étant donné le nombre de différences avec la version du site puls. Pour info j'ai mis un /* sam */ dans le source concernant mes modifs pour les retrouver facilement. Les changements sont très léger (3-4 endroits dans le code, pas plus.) [EDIT] oui je confirme, j'utilise ta version du 8/3/2017. La différence entre les deux sources est toute petite: https://www.cjoint.com/doc/19_04/IDEn4Vl05Ar_diff.htm (à gauche la version 8/3/2017, à droite mes modifs surlignées en orange) |
Auteur: | Prehisto [ 30 Avr 2019, 14:53 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Je peux te renvoyer les sources en l'état, si tu veux. Elles sont beaucoup plus lisibles maintenant que je les ai retravaillées. Mais le problème des EQU vers l'avant n'est pas encore entièrement résolu. |
Auteur: | Samuel Devulder [ 30 Avr 2019, 14:58 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Oui je veux bien tes dernier sources. Je peux reporter les modifs sans soucis. Il n'y a pas 15 lignes de modifiées en tout je pense D'ailleurs par rapport aux optims des sauts courts, j'ai vu qu'on pouvait aussi parfois remplacer des BRA *+2 par un FCB $8C (CMPX #nnnn, gain: 1 octet) et les BRA *+1 par un FCB $81 (CMPA #nn, grain: 1 octet et 1 cycle). Alors oui 1 octet c'est pas beaucoup, mais ca peut aider à garder le code dans la page directe le plus possible. Le jeu de macro que je me suis faite indique dans le commentaire qu'un BRA peut être optimisé par l'une des macro SKIP (à défaut de faire un vrai SKIP sous peine de voir les adresses suivantes décalées de 1 octet.) Plus généralement parlant, je me questionne sur l'intéret d'un optimisateur avancé en ASM: un truc qui prends un code ASM, fait une analyse et le réécrit en optimisant les sauts. Ainsi un Bcc sur un autre BRA ou un JMP pourrait être recombiné en un seul (L)Bcc; les sauts de 1 ou 2 octets en avants remplacés par des SKIP. Dans l'idéal ca serait bien que le compilo ASM fasse cela (optimisation peep-hole), mais on a vu que la gestion des adresses était délicate dans son cadre. |
Auteur: | Prehisto [ 30 Avr 2019, 17:03 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Samuel Devulder a écrit: Oui je veux bien tes dernier sources. Je peux reporter les modifs sans soucis. Il n'y a pas 15 lignes de modifiées en tout je pense Je viens de vérifier. Pour l'instant, elles sont trop buggées Samuel Devulder a écrit: D'ailleurs par rapport aux optims des sauts courts, j'ai vu qu'on pouvait aussi parfois remplacer des BRA *+2 par un FCB $8C (CMPX #nnnn, gain: 1 octet) Oui, astuce de programmation antédiluvienne. Samuel Devulder a écrit: et les BRA *+1 par un FCB $81 (CMPA #nn, grain: 1 octet et 1 cycle). Ou BRN, qui ne positionne aucun des flags de CC. (CMPA est moins gourmand, c'est vrai) Samuel Devulder a écrit: Plus généralement parlant, je me questionne sur l'intéret d'un optimisateur avancé en ASM: un truc qui prends un code ASM, fait une analyse et le réécrit en optimisant les sauts. Ainsi un Bcc sur un autre BRA ou un JMP pourrait être recombiné en un seul (L)Bcc; les sauts de 1 ou 2 octets en avants remplacés par des SKIP. Dans l'idéal ca serait bien que le compilo ASM fasse cela (optimisation peep-hole), mais on a vu que la gestion des adresses était délicate dans son cadre. Et la plupart du temps, en assembleur, l'optimisation est à l'initiative du programmeur. Et quand on veut faire une bonne optimisation, il faut voir plus loin que 2 instructions consécutives. Optimisation pour les débutants? |
Auteur: | Samuel Devulder [ 30 Avr 2019, 19:37 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Oui je suis assez d'accord que les meilleurs optims viennent du codeur. En plus le peep-hole sur 6809 est assez faiblard car on écrit plutôt facilement un code pas trop mauvais sans y réfléchir avec un tout petit peu d’expérience. Seule exception: le code généré par un compilateur C. Cette aprem j'ai regardé http://www.brouhaha.com/~eric/embedded/6809/ avec en particulier Citation: 221_01.zip ( 87K) 6809 C compiler for Flex qui prétend avoir un peephole. Ben les exemples d'asm pour les routines des bibliothèques C sont hyper mauvais. Les séquences "pshs d" .. "bidule ,s++" sont nombreuses. Le peephole optim ne voit même pas l'optim consistant à virer le ++ et remplacer le pshs d par un "std ,s" (sans doute parce qu'ensuite le offsets sur la pile sont à recalculer.) Bref ce compilo est pas terrible. A rewrite of Ron Cain's Small C targeted for 6809 processors running under the FLEX operating System. Dieter Flunker (Italy), has expanded slightly on the language subset implemented by Cain and includes a peephole code optimizer. Je sens que pour le fun, un jour je vais faire le miens. D'ailleurs j'ai trouvé la base avec >>c4<<. C'est un compilo C aussi puissant que ceux de FLEX (en gros il n'y a pas les bitsfields, ni les structs/union) mais tenant dans seulement 4 fonctions C. Plus de détails >>ici<<. |
Auteur: | Bentoc [ 07 Fév 2021, 14:53 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Salut, J'ai un comportement qui me parait étrange, mais peut-être que ça vient d'une mauvaise compréhension de ma part. Dans le cas d'un STU DYN_U+2,PCR l'écriture se fait en +2 par rapport à l'étiquette tout va bien. Par contre dans le cas d'un STY ou d'un STS DYN_S+2,PCR l'écriture se fait en +3 par rapport à l'étiquette donc un octet trop loin à mon sens. Code: /*--------------------------------------------------------------* * Compilé avec C6809 v0.83 * *--------------------------------------------------------------* * Fichier source : .\tmp\test.asm * Fichier destination : test.BIN * Contenu : * Main 0:TEST.ASM 317 *--------------------------------------------------------------*/ Macro Pass Pass1 Pass2 2 6200 org $6200 3 4 6+5 6200 10EF 8D 0003 STS DYN_S+2,PCR 5 6205 DYN_S 6 4 6205 10CE 0000 LDS #$0000 ---------------- 15 cycle(s) 9 byte(s) ---------------- 8 9 6+5 6209 10AF 8D 0003 STY DYN_Y+2,PCR 10 620E DYN_Y 11 4 620E 10CE 0000 LDS #$0000 ---------------- 15 cycle(s) 9 byte(s) ---------------- 13 14 5+5 6212 EF 8D 0002 STU DYN_U+2,PCR 15 6216 DYN_U 16 4 6216 10CE 0000 LDS #$0000 ---------------- 14 cycle(s) 8 byte(s) ---------------- Anomalie ou mauvaise compréhension ? |
Page 3 sur 4 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |