![]() |
![]() |
#1 |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 61
|
vasm - Warn when addressing absolute 16-bit memory?
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: Code:
move.w $10(a4),d0 Code:
move.w $10,d0 |
![]() |
![]() |
#2 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,300
|
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). |
![]() |
![]() |
#3 | |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 61
|
Quote:
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. |
|
![]() |
![]() |
#4 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 876
|
|
![]() |
![]() |
#5 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 830
|
Quote:
in source you can disable it in following way Code:
IFD BARFLY BOPT w4- ;disable 64k warnings ENDC ;END IFD BARFLY |
|
![]() |
![]() |
#6 |
Registered User
Join Date: Nov 2005
Location: United Kingdom
Age: 41
Posts: 126
|
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 |
![]() |
![]() |
#7 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
Quote:
equor 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 -warnabs16and -warnabs32. |
|
![]() |
![]() |
#8 | ||
Registered User
Join Date: Jun 2009
Location: United States
Posts: 61
|
Quote:
Quote:
clr.w SomeOffsetinstead 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. |
||
![]() |
![]() |
#9 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
Quote:
Quote:
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. |
||
![]() |
![]() |
#10 | |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 61
|
Quote:
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. |
|
![]() |
![]() |
#11 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
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.
Quote:
![]() Quote:
_LinkerDBand use vlink to create the final executable? Quote:
You can solve the problem with some linker-script magic. Then you can also use the NEARdirective in your modules again, but -picbecomes 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: Code:
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 Code:
vasmm68k_mot -Fvobj -o main.o main.asm vlink -bamigahunk -o program main.o -Fhunkor -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): Code:
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 Code:
SECTIONS { code 0 (NOLOAD): { *(CODE) *(picmodules) } sdata (NOLOAD): { _SDA_BASE_ = . + 32766; _LinkerDB = . + 32766; *(DATA) *(BSS) } mod: { *(mod*) } } NOLOADflag 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: Code:
vlink -brawbin1 -T modscript -o mod1 main.o mod1.o Code:
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 |
|||
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
16-Bit/32-Bit UK Computer Price Comparisons | Amigajay | Retrogaming General Discussion | 10 | 02 July 2020 17:12 |
Absolute addressing | Old_Bob | Coders. Asm / Hardware | 9 | 20 September 2018 10:36 |
Best Way to Convert 32-bit Signed Value to 16 Bit? | AGS | Coders. Asm / Hardware | 31 | 29 December 2013 13:58 |
Memory addressing | CmdrVimes | Coders. General | 7 | 25 October 2010 22:20 |
Memory Addressing Architecture | Zetr0 | support.Hardware | 2 | 10 July 2007 16:55 |
|
|