verbose listings appear in manual but show as deprecate in use

[PaoloFPugno]

Hello Edouard, I have been using RASM for an MSX project and reached a point where a verbose listing of the assembly process would be very useful. I consulted the documentation and it shows that there is a number of options (item 2.7). However, the ones I need show as "deprecated" on screen and no listing is generated. I can understand that these options are not used often, however it would have helped me a lot if they were still there. What is the latest RASM version to have these options enabled?

I fully understand that you have a reason not to include them anymore, however... I'd like to ask you to re-enable these debug options. Thank you in advance! Kudos for your amazing work!

[EdouardBERGE]

Hi the "-d" and "-a" options are VERY related to internal developpement of Rasm, not of regular assembly i doubt there is anything usable for you maybe you can use Disark (a tool provided with Arkos Tracker) if you need to dump/explode some portion of your code? => http://www.julien-nevo.com/arkostracker/index.php/download/ BTW i will open an issue for the documentation Let me know if you have a special need Regards

[cpcitor]

Hi Roudoudou, hi @PaoloFPugno

Very early on, I was also very surprised about the lack of verbose output from Rasm, which to me felt so opaque. On a CPC a byte is a byte. On a tight production I want to know where, which byte values, why.

In comparison, SDCC's assembler sdasz80 has a very old code base, lacks many bells and whistles of Rasm but it's much more open, flexible to incorporate into arbitrary workflow and the optional verbose output allows to see precisely what byte is generated where, for what reason, was it code, data, which symbol, assembler output before relocation, linker output after relocation.

Disark recovers what it can but it operates very late, so the generated output is less readable, sometimes messy, sometimes even wrong (at that point in the workflow it cannot guarantee against attributing some value/address to some symbol that happens to have the same value by accident, which is never a problem with a proper verbose output). Also, Disark is not open-source and I can't run it on Arm (e.g. Raspberry Pi).

Verbose output is also interesting when comparing outputs from the program given similar inputs (an option to output byte values but not their addresses comes handy to use automated comparison programs). This helps spot bugs in user code (or in Rasm), this can also help you in implementing relocatable output. These have synergy.

Keep up the good work, cheers!

[EdouardBERGE]

Yeah, i was thinking about that. This kind of debug has never existed in rasm, a sort of "map" output I may work on it ;)

[PaoloFPugno]

I think it could be useful for debug and documentation purposes, to show each line (with an option to expand or not the macros) and tge code it generates in hexadecimal. This way we can trace the various conditional assembly instructions, etc. Using a disassembly could help, but it means extra work and no vision of the path taken during assembly. An idea would be to indicate, next to each conditional branch, the contents of the labels being used in that test.

Em qua, 20 de abr de 2022 03:07, Edouard BERGE @.***> escreveu:

Yeah, i was thinking about that. This kind of debug has never existed in rasm, a sort of "map" output I may work on it ;)

— Reply to this email directly, view it on GitHub https://github.com/EdouardBERGE/rasm/issues/21#issuecomment-1103505684, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASJUGCRXRETFBSF6D3KU763VF6NIXANCNFSM5T2KB3MA . You are receiving this because you were mentioned.Message ID: @.***>

[EdouardBERGE]

here is a prototype (with latest commit) be aware that immediate values inside opcode will be always zeroed because the output is realtime, not buffered is it ok for you?

; SNAPINIT 'unsnap.sna'
; BANK
 MACHIN EQU 5*GLOP ; alias definition
; MACRO PLOT,X,Y
                                        ORG #8000 ; bank 0
 RADIUS=80 ; 80.00 | #0050
----- REPEAT 2,X
; Macro PLOT expansion with 2 parameters
 ZEUB=160+RADIUS*COS(X)]2 ; 60.00 | #003C
; SWITCH 160+RADIUS*COS(X)&3
 PIX=%10000000 ; 128.00 | #0080
 ADDY=(100+RADIUS*SIN(X)&7)*#800+(100+RADIUS*SIN(X)]3)*80 ; 11200.00 | #2BC0
 ADR=#C000+ZEUB+ADDY ; 60412.00 | #EBFC
[000]:[#8000]         | #21 #00 #00     LD HL,ADR
[000]:[#8003]         | #3E #00         LD A,PIX
[000]:[#8005]         | #B6             OR (HL)
[000]:[#8006]         | #77             LD (HL),A
----- REND ----- ; counter=1 Level 0 will loop again
 ZEUB=160+RADIUS*COS(X)]2 ; 60.00 | #003C
; SWITCH 160+RADIUS*COS(X)&3
 PIX=%10000000 ; 128.00 | #0080
 ADDY=(100+RADIUS*SIN(X)&7)*#800+(100+RADIUS*SIN(X)]3)*80 ; 15296.00 | #3BC0
 ADR=#C000+ZEUB+ADDY ; 64508.00 | #FBFC
[000]:[#8007]         | #21 #00 #00     LD HL,ADR
[000]:[#800A]         | #3E #00         LD A,PIX
[000]:[#800C]         | #B6             OR (HL)
[000]:[#800D]         | #77             LD (HL),A
----- REND ----- ; counter=2 Level 0 end of REPEAT
[000]:[#800E]         | #C9             RET
[000]:[#800F]         |                 SUIVANT ; label
                                        ORG #9000,#800F ; bank 0
 X=5 ; 5.00 | #0005
; Macro PLOT expansion with 2 parameters
 ZEUB=160+RADIUS*COS(X)]2 ; 60.00 | #003C
; SWITCH 160+RADIUS*COS(X)&3
 PIX=%10000000 ; 128.00 | #0080
 ADDY=(100+RADIUS*SIN(X)&7)*#800+(100+RADIUS*SIN(X)]3)*80 ; 7184.00 | #1C10
 ADR=#C000+ZEUB+ADDY ; 56396.00 | #DC4C
[000]:[#800F]:[#9000] | #21 #00 #00     LD HL,ADR
[000]:[#8012]:[#9003] | #3E #00         LD A,PIX
[000]:[#8014]:[#9005] | #B6             OR (HL)
[000]:[#8015]:[#9006] | #77             LD (HL),A
 GLOP EQU 2 ; alias definition

[PaoloFPugno]

I'd say it is a very good start. Of course, ideally, the values should appear instead of being zeroed (it helps in debugging because the value could be the result of a calculation based on declared constants and/or variables and depending on conditional branching. Also, if labels could be included as well, it would be great.

Here a snippet from a listing generated from a very basic assembler using a simple source (just as an example). Hope it helps!

Listing.txt

[EdouardBERGE]

There is already label in the prototype, see:

[000]:[#800F] | SUIVANT ; label

But if you missed it, i guess I miss something to make it more visible?

Something like this would be better, as there is no outputed byte?

[000]:[#800F] | ===LABEL=== SUIVANT

[cpcitor]

Good start.

But if you missed it, i guess I miss something to make it more visible?

I missed it too. :-)

Something like this would be better, as there is no outputed byte?

Why not something closer to initial ASM syntax like sdasz80 does?

It generates:

• .lst files where addresses are local to the module (which is handy to know how many bytes a module consumes and compare after any change) and any address that will finally become absolute is written as zero
• .rst files where bytes and addresses have final value

Example

Here's an example .rst from a minor graphical routine in Just Get 9 (github has a funny syntax coloration, I guess it is confused because it's not exactly asm :shrug: )

Also notice:

• actually sdasz80 supports unofficial z80 instructions without the need for macros, I didn't know that when writing that code.
• in brackets are timing in number of NOPs -- normal sdasz80 outputs number of Z80 t-states, but in cpc-dev-tool-chain sdcc is automatically patched to output Amstrad CPC timing.

003388                          7 _darken_screen::
003388 EB               [ 1]    8         ex de,hl
003389 21 00 C0         [ 3]    9         ld hl,#0xc000
                               10 
000004                         11         ld__iyl_nn #8   ; this is a macro
00338C FD 2E 08                 1 .db 0xfd, 0x2e, #8
                               12 
00338F                         13 next_block:
00338F 01 08 00         [ 3]   14         ld bc,#0x0008
                               15 
                               16         ;; b must be zero for proper counting
003392                         17 next_byte:
003392 7E               [ 2]   18         ld a,(hl)
003393 A3               [ 1]   19         and e
003394 77               [ 2]   20         ld (hl),a
003395 2C               [ 1]   21         inc l
003396 10 FA            [ 4]   22         djnz next_byte          ; done 0x100 bytes
                               23 
                               24         ;; now b=0 again, time to increment h
003398 24               [ 1]   25         inc h
003399 0D               [ 1]   26         dec c
00339A 20 F6            [ 3]   27         jr nz, next_byte        ; done 0x800 bytes
                               28 
                               29         ;; time to change pattern
                               30 
00339C 7A               [ 1]   31         ld a,d
00339D 53               [ 1]   32         ld d,e
00339E 5F               [ 1]   33         ld e,a
                               34 
000017                         35         dec__iyl
00339F FD 2D                    1 .db 0xfd, 0x2d
0033A1 20 EC            [ 3]   36         jr nz, next_block
                               37 
0033A3 C9               [ 3]   38         ret

[cpcitor]

Why not something closer to initial ASM syntax like sdasz80 does?

Answering my own question, rasm accepts plain words as label without a ":". I consider this not desirable because it hinders readability. On second reading your sample is relatively close to my sample.

[PaoloFPugno]

Yes, actually I missed the label in the proposed prototype. We surely need a means of improving its visibility. I like @cpcitor suggestion above. The timing equivalence in NOPs is also very helpful. I like the way this is developing!

[EdouardBERGE]

i added ':' separator for labels, nop (or ticks!) timing + location in files the immediate values wont be added as it's not relevant (they are not existing during the output, Rasm is monopass and that wont change)