vasm - Warn when addressing absolute 16-bit memory?

[dansalvato]

Hello, I'm wondering if it's possible for vasm (or something else in the build stack) to provide a warning if an instruction is addressing an absolute 16-bit memory address. This only ever happens in my code if I typo, so it would help a lot to preemptively find these bugs if the assembler could warn me about it.

For example, sometimes I accidentally type something like this:

move.w $10(a4),d0

As this:

move.w $10,d0

Any suggestions on how to catch this during build?

[paraj]

Maybe I'm wrong, but I doubt any amiga assembler would warn about that. The major issue being the obviously correct

move.l 4.w,..

and less (depending on context) reading/setting of interrupt routines.

Is this really an issue you've encountered with literal offsets or only with "named" offsets? Asking because I've not really had an issue with the former, while the later might be worth looking at adding more "guard rails" for if possible in a compatible way (IMO).

[dansalvato]

Originally Posted by paraj

Maybe I'm wrong, but I doubt any amiga assembler would warn about that. The major issue being the obviously correct

move.l 4.w,..

and less (depending on context) reading/setting of interrupt routines.

Is this really an issue you've encountered with literal offsets or only with "named" offsets? Asking because I've not really had an issue with the former, while the later might be worth looking at adding more "guard rails" for if possible in a compatible way (IMO).

This is a good point. I only encounter it with named offsets, and only during part of the build process where I use the -pic (position-independent code) assembler option. I have module files that I build with -pic that are only supposed to address memory using a base register.

I could do this the quick and dirty way by writing a script that parses my code and looks for these errors, but I was just hoping a more formal mechanism existed.

[NorthWay]

Originally Posted by paraj

Maybe I'm wrong, but I doubt any amiga assembler would warn about that.

Something in the back of my head says BAsm will get cranky about it unless opted out?

[Asman]

Originally Posted by NorthWay

Something in the back of my head says BAsm will get cranky about it unless opted out?

yes, as far as I remember, basm generate warning about that by default.

in source you can disable it in following way

 IFD BARFLY

 BOPT   w4-            ;disable 64k warnings

 ENDC	;END IFD BARFLY

[DJ Mike]

Yes, Barfly definitely warns about vector accesses by default. I get caught out by this when recompiling disassembled game code.

My similar typo mistake is usually forgetting to put # when using constants, e.g.

move.b $10,d0

instead of:

move.b #$10,d0

[phx]

Originally Posted by dansalvato

I only encounter it with named offsets, and only during part of the build process where I use the -pic (position-independent code) assembler option.

Then these named offsets are no labels, but equates? And you don't use the small-data model but absolute offsets, defined by

equ

or

rs

? With real labels and small-data your problem would disappear, because the PIC mode generates an error for everything which may need a relocation entry.

Otherwise, I could add an option to print warnings for any 16- or 32-bit absolute addressing mode, if anybody thinks this is useful. Maybe something like

-warnabs16

and

-warnabs32

.

[dansalvato]

Originally Posted by phx

Then these named offsets are no labels, but equates? And you don't use the small-data model but absolute offsets, defined by

equ

or

rs

? With real labels and small-data your problem would disappear, because the PIC mode generates an error for everything which may need a relocation entry.

Correct, these are equates. I have some independent modules I build in PIC mode, but they use a base register from the main program. Therefore, I can't use real labels and benefit from the assembler's small-data feature. I just give the modules a list of equates with important base-relative offsets from the main program.

Originally Posted by phx

Otherwise, I could add an option to print warnings for any 16- or 32-bit absolute addressing mode, if anybody thinks this is useful. Maybe something like

-warnabs16

and

-warnabs32

.

The main thing that bites me is specifically when 16-bit absolute addressing is happening via an equate. There's a very high chance that the address register was accidentally omitted from the instruction, e.g.

clr.w SomeOffset

instead of

clr.w SomeOffset(a4)

. I imagine this mistake is pretty common, and it's not just me.

In any case, I'd be very grateful and benefit from the warning option you suggest, whether or not the option cares about equate vs. literal.

[phx]

Originally Posted by dansalvato

I have some independent modules I build in PIC mode, but they use a base register from the main program. Therefore, I can't use real labels and benefit from the assembler's small-data feature.

I would bet that it is possible even in this case. If you are interested we can discuss that further.

In any case, I'd be very grateful and benefit from the warning option you suggest, whether or not the option cares about equate vs. literal.

Done. Please try tomorrow's daily source snapshot:
http://sun.hasenbraten.de/vasm/index.php?view=source

The new options care about absolute vs. relocatable symbols, so the warning will never trigger on section labels.

[dansalvato]

Originally Posted by phx

I would bet that it is possible even in this case. If you are interested we can discuss that further.

Done. Please try tomorrow's daily source snapshot:
http://sun.hasenbraten.de/vasm/index.php?view=source

The new options care about absolute vs. relocatable symbols, so the warning will never trigger on section labels.

Beautiful! Thank you very much.

I'm happy to hear your thoughts about my build, but we don't need to jump down a rabbit hole since my current system is working well (even if a bit silly).

My main program builds with small-code and small-data, and I use the NEAR directive with a4. During build, I generate the map file with vasm, and then use a simple script to reformat the map file into a symbols.i file that I include in my PIC modules.

I run vasm separately for each of the PIC modules. They're built with -Fbin. When loaded at runtime, they interact with the main program by using a4 for data and a5 for code.

The entire build process only takes 500ms or so. The only drawback to this system is that in the PIC modules, I need to explicitly put a4 and a5 in my instructions, whereas the NEAR directive prevents that in the main program. But this is hardly a drawback, especially with the new feature you just added to help with potential typos.

[phx]

I just noticed that Volker's CVS-server was not reachable last night, so the nightly source export didn't work. Please try again tomorrow.

Originally Posted by dansalvato

I'm happy to hear your thoughts about my build, but we don't need to jump down a rabbit hole since my current system is working well (even if a bit silly).

Absolutely. But sometimes things can be much easier, if you only knew about it. Also for future projects.

My main program builds with small-code and small-data, and I use the NEAR directive with a4.

Then you initialize a4 with

_LinkerDB

and use vlink to create the final executable?

I run vasm separately for each of the PIC modules. They're built with -Fbin. When loaded at runtime, they interact with the main program by using a4 for data and a5 for code.

Ok. I understand. So a5 points to the start address of the main program's code section?

You can solve the problem with some linker-script magic. Then you can also use the

NEAR

directive in your modules again, but

-pic

becomes useless, because vasm has to create 16-bit absolute relocations for the function calls via A5.

Here is an example which I just made. I assume that the binary modules are dynamically loaded into some allocated space. The DATA and BSS section will be automatically recognized as small-data section due to base-relative references. The main program, main.asm:

        near    a4
        xref    _LinkerDB

        code
start:
        lea     _LinkerDB,a4
        lea     start(pc),a5
        ;jsr    loadmodule
        jsr     picmods
        rts

        xdef    func1
func1:
        move.w  ivar(a4),d1
        add.w   d0,d1
        move.w  d1,uvar(a4)
        rts

        xdef    func2
func2:
        addq.w  #1,uvar(a4)
        rts

        data
        xdef    ivar
ivar:   dc.w    1

        bss
        xdef    uvar
uvar:   ds.w    1

        section picmodules,code
picmods:
        ds.b    1024

You will probably build it with:

vasmm68k_mot -Fvobj -o main.o main.asm
vlink -bamigahunk -o program main.o

The object file format is irrelevant. You can also use

-Fhunk

or

-Felf

. It is only important to keep the main program's object files for the module-linking.

A module could look like this (mod1.asm):

        xref    func1
        xref    func2
        xref    uvar
        near    a4

        section mod1,code

        bsr     init
        moveq   #1,d0
        jsr     func1(a5)
        jsr     func2(a5)
        rts

init:
        clr.w   uvar(a4)
        rts

Assemble it in the same way into an object file (mod1.o), then link it using this linker script (called modscript):

SECTIONS {
        code 0 (NOLOAD): { *(CODE) *(picmodules) }
        sdata (NOLOAD): {
                _SDA_BASE_ = . + 32766;
                _LinkerDB = . + 32766;
                *(DATA)
                *(BSS)
        }
        mod: { *(mod*) }
}

Note, that all sections from the main program got a

NOLOAD

flag in the output section, so they are not loaded into the output binary. The code-section should start at 0 to give us the correct A5-offsets. The small data base is defined in the usual way to allow vlink to do the correct SD-reloc calculations. Last follows the output section for the module. The only section which is written to the output. Link it into a raw binary file with:

vlink -brawbin1 -T modscript -o mod1 main.o mod1.o

When disassembling mod1 you see the offsets are correct:

frank@nerthus vda68k mod1
00000000: 610c                      bsr.b   0xe
00000002: 7001                      moveq   #0x1,d0
00000004: 4ead 0012                 jsr     0x12(a5)
00000008: 4ead 001e                 jsr     0x1e(a5)
0000000c: 4e75                      rts
0000000e: 426c 8004                 clr.w   -0x7ffc(a4)
00000012: 4e75                      rts