C6809 version 0.83, alors ?

Prehisto · **Posté:** 15 Mar 2010, 12:08

La version 0.83 de c6809 vous attend bla bla bla.

Samuel Devulder · **Posté:** 17 Oct 2017, 14:22

Ah! Je pense avoir découvert un petit bug dans le calcul des cycles lors d'un saut indirect:

Code:

96 3+3 759C 6E 9F 7800 f_loop jmp [cores] ; 8

En effet, il est compté 3+3=6 cycles. Or dans la doc 6809, je vois que [n] compte pour 5 cycles et pas 3.

Je ne sais pas si ce bug existe sur les autres versions de c6809.

Prehisto · **Posté:** 17 Oct 2017, 15:23

Oui, c'est corrigé dans la dernière version à compiler que je t'ai envoyée.

Samuel Devulder

Tiens, je déterre ce sujet parce que j'ai découvert sur l'asm 68000 une macro intéréssante: REPT n/END. Cela permet de repéter n fois un bloc de code. Alors certes, il y a cette solution, mais c'est moins pratique car il faut définir une macro spécifique pour le code à répéter alors que

Code:

REPT 10
inca
decb
mul
ENDR

me semble plus lisible.

On a pas cette macro-instruction REPT/ENDR dans les assembleurs thomson il me semble, non ?

Prehisto

Samuel Devulder a écrit:

On a pas cette macro-instruction REPT/ENDR dans les assembleurs thomson il me semble, non ?

Pas encore.

GarlandRaven · **Inscription:** 08 Oct 2018, 17:24 **Messages:** 18

Sorry guys for the newbie question. I'm using C6809 for the first time. I transcripted my code and followed the example.ass but the assembly phase wont link external references. What i'm missing?

Also, two sides questions: 1) im using notepad++, do you know a better editor for asm? 2) At which address i should load the raw bin in the debug setting of dcmoto?

Thank you so much

Samuel Devulder · **Posté:** 18 Oct 2018, 20:43

Actually with C6809 all the *.ASM files are contained in a single file (usually with *.ASS as extension). Each *ASM file is described in a section defined by the (main) or (include) prefix. C6809 will read these sections as independent ASM files and perform INCLUD (notice: no "E") with respect to these section-files.

In your case the file should look like this:

Code:

(main)BLANKALL
* no need to put extension to BLANKALL

* Your code here
FOO EQU $000
BAR:
       lda #1
* etc...

* your includes
       INCLUD MOGFX
       INCLUD MOINPUT
* end of main: entry point will be BAR
       end  BAR
* BLANKALL.ASM will end here

(include)MOGFX
* here is the source that will go to MOGFX.ASM and
* included at INCLUD MOGFX above.
     bla bla
* MOGFX.ASM ends here

(include)MOINPUT
* here is the source that will go to MOINPUT.ASM and
* included at INCLUD MOINPUT in the (main) section above.
     bla bla
* MOINPUT.ASM ends here

I'm not sure if I am clear, but to sum-up I'd say that C6809 is a bit special with respect to multiple files. Basically an ASS file compiled by C6809 contains virtual files that are represented by (main) or (include) sections. At the end of the compilation you get on disk as many ASM files as defined sections and a BIN file corresponding to the compilation of the (main) section. The BIN file is in thomson format and can be loaded and executed on the machine. If you provide the "-bd" option on the command-line for the compilation, that "BIN" file will be in RAW format ('d' stands for plain data) that you can copy into DCMOTO memory directly using the built-in debugger.

GarlandRaven · **Inscription:** 08 Oct 2018, 17:24 **Messages:** 18

Quite clear, thanks Sam.

Two issues:

1) Macros calls seems to crash C6809 (even a simple macro) on Pass 1 - i'm on Windows 8.1 and it raises unhandled ex

2) This code:

Code:

BUFK FCB $62,$42,$52

Which was perfectly legit before, is now marked as "binary not linear" error when assembling. I googled for that but found nothing, sorry if i'm asking you again.

Cheers

Samuel Devulder · **Posté:** 18 Oct 2018, 22:11

For point 1), I can't tell. I've never come to c6809 crash. This is an issue for Prehisto I guess (the author), but he'll need the source code to reproduce the issue I guess.

Concerning Point 2), the error message means something that needs fixing. As a matter of fact, it its not directly related to the FCB itself, but possibly to the fact that this FCB overlap another memory region (ORG directive) or some RMB instruction creates an empty space in the binary, both resulting in non-linear memory map. You can inspect the code.lst file to try to guess what is going wrong here (look for memory locations not being continuous). Maybe compiling with "-bh" (hybrid binary) in place of "-bl" (linear binary), will help. It'll allow overlapping or gaps in the binary file, but it won't fix the overlap itself if there is one (Gaps are harmless and can be fixed by providing a 2nd parameter ro the RMB command (eg RMB nnn,0) to fill the gap with some value.)

GarlandRaven · **Inscription:** 08 Oct 2018, 17:24 **Messages:** 18

Yes, that was an RMB which was giving no issues on MA 3.6

I attached a .ASS with a very simple macro call which crashes the C6809 assembling process on Win 8.1: if you comment the call, it works.

Samuel Devulder · **Posté:** 04 Mar 2019, 08:15

Ah! je suis tombé sur un truc rigolo dans c6809. C'est pas vraiment un bug d'assemblage, mais un bug de comptabilité des cycles. En effet, il considère que "ORCC #nn" s'effectue en 2 cycles, alors qu'il lui en faut 3 d'après la doc 6809.

Code:

     90  3     7322 25   06               bcs     vXa    ; 3 => 11
     91  8     7324 1E   88               exg     a,a    ; 8
     92  2     7326 1A   01               orcc    #1     ; 3
         ^ DEVRA1T ETRE 3
     93  3     7328 20   08               bra     vXb    ; 3 => 14

Prehisto · **Posté:** 04 Mar 2019, 09:26

Effectivement. Et ANDCC aussi.

Samuel Devulder

Je suis en train de me faire un set de macro-instructions pour me faciliter l'écriture d'algorithmes complexes en ASM. J'en dirais plus à ce sujet plus tard, mais en travaillant dessus je suis tombé sur une difficulté.

La problématique posée est celle ci: écrire une macro "JP label" qui, en fonction du label passe automatiquement entre un BRA et un JMP. Je me suis dit que c'était pas bien compliqué d'écrire une macro qui test la distance entre *+2 et lbl et si c'est entre -128 et 127 fait un BRA label et JMP label sinon. Ca donne quelque chose comme ceci:

Code:

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

Bon.

Je teste quelques cas:

Code:

      JP      L1
L0
      RMB      126,0
L1
      JP      L0
      echo   L0=$L0
      echo   L1=$L1

Et là surprise, c6809 0.83 me donne

Code:

    159                                   IFEQ    (L1-*-2)&$FF80
    160  3     9000 20   7F               bra     L1  ; branchements positi>>
    161                                   ELSE
    162                                   IFEQ    (*+1-L1)&$FF80
    163                                   bra     L1  ; branchements negati>>
    164                                   ELSE
    165                                   jmp     L1
    166                                   ENDC
    167                                   ENDC
    171        9002               L0
    172        9002                       RMB     126,0
    173        9080               L1
    159                                   IFEQ    (L0-*-2)&$FF80
    160                                   bra     L0  ; branchements positi>>
    161                                   ELSE
    162                                   IFEQ    (*+1-L0)&$FF80
    163  3     9080 20   81               bra     L0  ; branchements negati>>
    164                                   ELSE
    165                                   jmp     L0
    166                                   ENDC
    167                                   ENDC

On voit que les offsets des BRA sont faux. Pour aller de $9002 à $9080 c'est un +126 (taille du RMB) qu'il faudrait et on obtient un +127. A l'inverse pour aller dans l'autre sens c'est -128 qu'il faut et on obtient -127. Bref les sauts sont 1 octet trop long ou trop court. C'est confirmé avec ce qu'on voit sur la console:

Code:

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 $9003
L0=$9003
L1=$9081

000000 Total Errors

Et oui, pour l'assembleur L0 et L1 ne correspondent pas à ce qu'on voit dans le fichier CODE.LST qui est généré et qui contient l'asm vraiment produit.

D'où est-ce que cela peut provenir ? J'imagine que cela vient du fait que la macro est de taille variable (particularité de cette macro). Si le IF est vrai, alors il y a 2 octets de code (ce qu'on voit dans le code.lst), sinon 3 (ce qu'on voit dans la console). Ca doit pouvoir expliquer le décalage de 1 si le calcul des adresses interpréte mal le IF.

Ca m'ennuie parce que je commençais à utiliser cette macro un peu partout et que le décalage introduit fait complètement bugger les trucs en sautant en plein milieu d'une instruction.

Prehisto

Oui, c'est un des problèmes de c6809.

Pour calculer les premiers IF dans ta macro, il faudrait que l'assemblage connaisse la valeur de L1. Or, il ne la connaît pas encore. Donc il doit se tromper dans le calcul d'offset, faire un JMP en première passe, et faire un BRA en deuxième passe. D'où l'erreur.

Samuel Devulder

Les adresses ne sont pas modifiées en 2e passe quand il s'apperçoit que le IF a changé de sens ? Il faudrait faire autant de passe tant qu'on a pas atteint un point fixe dans la valeur de vérité des IF (ou des variables) et prendre les adresses à ce moment là. Ca fait probablement une grosse modif du code.

Logicielsmoto.com

C6809 version 0.83, alors ?

Qui est en ligne