verbose listings appear in manual but show as deprecate in use about rasm HOT 11 CLOSED

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 ;)

from rasm.

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 🤷 )

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

from rasm.

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

from rasm.

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!

from rasm.

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

from rasm.

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.

from rasm.

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)

from rasm.

from rasm.

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

from rasm.

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

from rasm.

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!

from rasm.