12 August 2024, 19:35 | #1 |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
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 |
12 August 2024, 20:37 | #2 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,311
|
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). |
12 August 2024, 21:44 | #3 | |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
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. |
|
13 August 2024, 00:34 | #4 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 877
|
|
13 August 2024, 11:08 | #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 |
|
13 August 2024, 11:22 | #6 |
68k Abuser
Join Date: Nov 2005
Location: United Kingdom
Age: 41
Posts: 140
|
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 |
15 August 2024, 15:52 | #7 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,580
|
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. |
|
15 August 2024, 16:21 | #8 | ||
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
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. |
||
16 August 2024, 15:45 | #9 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,580
|
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. |
||
17 August 2024, 23:11 | #10 | |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
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. |
|
18 August 2024, 16:41 | #11 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,580
|
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.
EDIT: There server has still problems. Here is an archive with the two updated files: http://sun.hasenbraten.de/~frank/TES..._update.tar.gz 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 Last edited by phx; 19 August 2024 at 11:51. Reason: Link to patched files |
|||
19 August 2024, 23:41 | #12 |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
Wow, thanks so much for the thorough explanation and example. I knew there had to be a way to do this via linker script, but I have no experience with linkers, so I didn't know where to start.
I'll find some time to mess around with this and update if/when I find success with it. You've been a huge help. |
21 August 2024, 01:40 | #13 |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
I spent today refactoring my module code to make use of a linker script, and it's helped simplify a ton of my code. I'm now using a NEAR directive instead of explicitly adding a4, and pc-relative references are also resolved automatically.
Here is my script: Code:
SECTIONS { modsyms (NOLOAD): { _SDA_BASE_ = . + 32766; _LinkerDB = . + 32766; *(__MERGED) } module: { *(modhead) *(module) *(moddata) } } There are other details that are too much to get into without explaining the ins and outs of my program, but this just about solves all of the pitfalls and added complexity I was previously dealing with when writing modules. |
22 August 2024, 11:43 | #14 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,580
|
Quote:
And calling functions via A5 is gone? Otherwise I don't see how it is working now. |
|
22 August 2024, 20:20 | #15 | |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
Quote:
Code:
dc.w SomeDataLabel-DataStart Here is a simple reproduction: Code:
SECTION __MERGED,DATA DataStart: dcb.b 128 SECTION __MERGED,BSS SomeDataLabel: dcb.w 1 ; This works fine SECTION __MERGED,DATA dc.w SomeDataLabel-DataStart ; Illegal relocation SECTION somesection,DATA dc.w SomeDataLabel-DataStart |
|
Yesterday, 16:46 | #16 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,580
|
Quote:
Quote:
So how is it changed to "somesection" when the main source obviously named it "__MERGED,data"? I assume you are doing in the module-source: Code:
include "mainprog.asm" section module,code mymodulecode: |
||
Yesterday, 21:49 | #17 | |
Registered User
Join Date: Jun 2009
Location: United States
Posts: 68
|
Quote:
module. The offsets I mentioned are not just in the main program, but in the module as well. When I include the main program in front of a module, vasm can't handle the relocation between __MERGED,DATAand __MERGED,BSSspecifically for offsets in the modulesection (it still handles them fine in the __MERGEDsection of the main program). However, the symbol generator takes all the data + BSS symbols from the main program and puts them all in a single __MERGED,BSSsection. So, those offsets in the modulesection don't get a relocation error. That's why it works when using the symbol generator, but it doesn't work when replacing that with including the full main program. Example of my code that only works with the generated symbols: Code:
INCLUDE "main.s" SECTION module,data ModuleStart: dc.w SomeBssOffset-DataStart SomeBssOffset-DataStartall over the main program, but there is no relocation error because they all live in __MERGED,DATA. It's only the ones in the modulesection that require the generated symbols to work. Last edited by dansalvato; Yesterday at 21:56. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
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 |
|
|