Logicielsmoto.com http://www.logicielsmoto.com/phpBB/ |
|
C6809 version 0.83, alors ? http://www.logicielsmoto.com/phpBB/viewtopic.php?f=10&t=362 |
Page 1 sur 4 |
Auteur: | Prehisto [ 15 Mar 2010, 12:08 ] |
Sujet du message: | C6809 version 0.83, alors ? |
La version 0.83 de c6809 vous attend bla bla bla. |
Auteur: | Samuel Devulder [ 17 Oct 2017, 14:22 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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. |
Auteur: | Prehisto [ 17 Oct 2017, 15:23 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Oui, c'est corrigé dans la dernière version à compiler que je t'ai envoyée. |
Auteur: | Samuel Devulder [ 17 Aoû 2018, 13:16 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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 me semble plus lisible.inca decb mul ENDR On a pas cette macro-instruction REPT/ENDR dans les assembleurs thomson il me semble, non ? |
Auteur: | Prehisto [ 17 Aoû 2018, 15:41 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Samuel Devulder a écrit: On a pas cette macro-instruction REPT/ENDR dans les assembleurs thomson il me semble, non ? Pas encore. |
Auteur: | Samuel Devulder [ 18 Oct 2018, 20:43 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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. |
Auteur: | GarlandRaven [ 18 Oct 2018, 21:49 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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 |
Auteur: | Samuel Devulder [ 18 Oct 2018, 22:11 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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.) |
Auteur: | GarlandRaven [ 19 Oct 2018, 00:52 ] | ||
Sujet du message: | Re: C6809 version 0.83, alors ? | ||
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.
|
Auteur: | Samuel Devulder [ 04 Mar 2019, 08:15 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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 |
Auteur: | Prehisto [ 04 Mar 2019, 09:26 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
Effectivement. Et ANDCC aussi. |
Auteur: | Samuel Devulder [ 10 Avr 2019, 20:28 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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 Bon.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 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. |
Auteur: | Prehisto [ 10 Avr 2019, 23:40 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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. |
Auteur: | Samuel Devulder [ 10 Avr 2019, 23:45 ] |
Sujet du message: | Re: C6809 version 0.83, alors ? |
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. |
Page 1 sur 4 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |