Redefining or undefining vasm macros

[hop]

I'm trying to use vasm to assemble a disk image containing file binaries and associated file table, using a C preprocessor pattern. Here's a contrived example:

FileList.h:

// n.b. No include guards in this header, which is designed to be included multiple times in the same compilation unit.
#ifndef FILE_LIST_MACRO
#error FILE_LIST_MACRO is not defined
#endif

FILE_LIST_MACRO(FileA);
FILE_LIST_MACRO(FileB);
...

#undef FILE_LIST_MACRO  // allow macro to be redefined

main.cpp: note that FILE_LIST_MACRO can be redefined within the same file.

#define FILE_LIST_MACRO(T) static File* Get##T() {...}
#include "FileList.h"

#define FILE_LIST_MACRO(T) static int GetSize##T() {...}
#include "FileList.h"

I can almost translate this pattern to VASM to generate a disk image containing filetable and file binaries. However, I can't manage to re-define a macro within a file. Here's what I have had to use instead (simplified):

FileList.inc:

	FILE_MACRO	caves_.cms
        FILE_MACRO      city__.cms

FileList2.inc: (don't want this file!)

	FILE_MACRO2	caves_.cms
        FILE_MACRO2	city__.cms

DiskImage.asm:

	ORG 0
	INCLUDE "bootblock"
	ORG $400

FILE_TABLE_OFFSET	EQU	$50000
FILE_TABLE_SIZE_BYTES	EQU	$1800	; original format
	ORG	FILE_TABLE_OFFSET
	; Use vasm macros to generate file table

	MACRO	FILE_MACRO	; \1 = file name
	DC.B	'\1'		; filename
	DCB.B	16-\?1,0	; zero-pad to 16 bytes
	DC.L	\1 	 	; disk address
	DC.L	\1_SIZE_BYTES	; size in bytes
	ENDM
	INCLUDE "FileList.inc"

	ASSERT *-FILE_TABLE_OFFSET<=FILE_TABLE_SIZE_BYTES
	ORG	FILE_TABLE_OFFSET+FILE_TABLE_SIZE_BYTES

Files:
	MACRO	FILE_MACRO2 		; want to re-use FILE_MACRO here
\1:	INCBIN	"Files/\1"
\1_SIZE_BYTES:	EQU	*-\1
	ENDM
	INCLUDE "FileList2.inc" ; want to include FileList.inc here

If I try this:

DiskImage.asm:

	ORG 0
	INCLUDE "bootblock"
	ORG $400

FILE_TABLE_OFFSET	EQU	$50000
FILE_TABLE_SIZE_BYTES	EQU	$1800	; original format
	ORG	FILE_TABLE_OFFSET
	; Use vasm macros to generate file table

	MACRO	FILE_MACRO	; \1 = file name
	DC.B	'\1'		; filename
	DCB.B	16-\?1,0	; zero-pad to 16 bytes
	DC.L	\1 	 	; disk address
	DC.L	\1_SIZE_BYTES	; size in bytes
	ENDM
	INCLUDE "FileList.inc"

	ASSERT *-FILE_TABLE_OFFSET<=FILE_TABLE_SIZE_BYTES
	ORG	FILE_TABLE_OFFSET+FILE_TABLE_SIZE_BYTES

Files:
	MACRO	FILE_MACRO
\1:	INCBIN	"Files/\1"
\1_SIZE_BYTES:	EQU	*-\1
	ENDM
	INCLUDE "FileList.inc"

Then there are errors:

error 3007: undefined symbol <city__.cms_SIZE_BYTES>
error 3007: undefined symbol <city__.cms>
error 3007: undefined symbol <caves_.cms_SIZE_BYTES>
error 3007: undefined symbol <caves_.cms>

n.b. Assembling with -ldots option.

Is it possible to achieve this? Thanks for any advice.

[phx]

Originally Posted by hop

I can almost translate this pattern to VASM to generate a disk image containing filetable and file binaries. However, I can't manage to re-define a macro within a file.

To make this work you would have to undefine the macro first, as you did in your example for the C preprocessor.

Good news is that vasm can indeed undefine macros. But the mot-syntax module doesn't implement any directive to do that. Only madmac-syntax offers

macundef

for now.

And then there might also be a bug, which I should address soon: The second macro definition with the same name shouldn't be accepted without error message (but I have to check other assemblers first).

Before you ask: Yes, maybe I could implement a macro-undef directive for mot-syntax. But I have rarely seen one among assemblers following the Motorola syntax, and I would prefer to adopt a directive which is commonly used instead of inventing new ones.

[hop]

Originally Posted by phx

To make this work you would have to undefine the macro first, as you did in your example for the C preprocessor.

Good news is that vasm can indeed undefine macros. But the mot-syntax module doesn't implement any directive to do that. Only madmac-syntax offers

macundef

for now.

And then there might also be a bug, which I should address soon: The second macro definition with the same name shouldn't be accepted without error message (but I have to check other assemblers first).

Thanks very much for explaining this. I was confused because it looked like it should work, but didn't. Adding an error message when a macro is redefined sounds like a good idea if it is straightforward.

Originally Posted by phx

Before you ask: Yes, maybe I could implement a macro-undef directive for mot-syntax. But I have rarely seen one among assemblers following the Motorola syntax, and I would prefer to adopt a directive which is commonly used instead of inventing new ones.

I don't think it is worth it. I was just seeing what could be done with the current feature set.

Using filenames as labels was a bad idea too! Filenames starting with numbers (5000pts.bal) didn't work with the macro and filenames containing hyphens (bonus--1.ald) were no good as labels. I tried renaming (invasive), and prefixing the generated labels with an underscore e.g. _\1 and hit further problems that I didn't understand. I couldn't see how to use the the unique id / global id / stack to connect the labels in the generated output of two seperate sets of macro invokations.

I've come to the conclusion that programatically generated assembly language in the build pipeline is the way to go. Far more flexible and straightforward.

Thanks again.

EDIT: Is it possible to view the generated vasm asm after macro expansion?

[Wepl]

Originally Posted by phx

And then there might also be a bug, which I should address soon: The second macro definition with the same name shouldn't be accepted without error message (but I have to check other assemblers first).

Silently redefining macros is a ugly thing. I had this recently and spent some time to find out that this was the reason.
Should at least throw a warning.

[phx]

Originally Posted by hop

I was confused because it looked like it should work, but didn't.

Yes, by accident it will even work most of the time, as the new macro is seen before the old one in the hash table.

Adding an error message when a macro is redefined sounds like a good idea if it is straightforward.

Abolutely! (Now I compared with some other assemblers.)

I've come to the conclusion that programatically generated assembly language in the build pipeline is the way to go. Far more flexible and straightforward.

Always use the best tools for the job!

Is it possible to view the generated vasm asm after macro expansion?

In the listing file? Here is my (working) example for macro redefinition:

abc     macro
        dc.l    \1
        endm

        abc     1

abc     macro
        dc.b    "\1",0
        endm

        abc     hej

The listing file:

Source: "tst.s"
                                     1: abc     macro
                                     2:         dc.l    \1
                                     3:         endm
                                     4:
                                     5:         abc     1
00:00000000 00000001                 1M         dc.l    1
                                     6:
                                     7: abc     macro
                                     8:         dc.b    "\1"
                                     9:         endm
                                    10:
                                    11:         abc     hej
00:00000004 68656A                   1M         dc.b    "hej"
                                    12:

The expanded macro lines got a capital 'M' attached to their line number.

Originally Posted by Wepl

Silently redefining macros is a ugly thing. I had this recently and spent some time to find out that this was the reason.

Agreed. Fixed it. You may try tomorrow's source snapshot.

[hop]

Originally Posted by phx

Yes, by accident it will even work most of the time, as the new macro is seen before the old one in the hash table.

Here is my (working) example for macro redefinition:

abc     macro
        dc.l    \1
        endm

        abc     1

abc     macro
        dc.b    "\1",0
        endm

        abc     hej

Agreed. Fixed it. You may try tomorrow's source snapshot.

Many thanks for making the change to catching macro redefinition. I've tested on Windows with your example code and it seems to be working as expected.

vasm 1.9a:

vasm 1.9a (c) in 2002-2022 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.5c (c) 2002-2022 Frank Wille
vasm motorola syntax module 3.16 (c) 2002-2022 Frank Wille
vasm binary output module 2.1 (c) 2002-2021 Volker Barthelmann and Frank Wille

CODE(acrx1):               8 bytes

vasm 2.0beta (daily source snapshot 06/01/2024):

vasm 2.0beta (c) in 2002-2024 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.6c (c) 2002-2023 Frank Wille
vasm motorola syntax module 3.18 (c) 2002-2023 Frank Wille
vasm binary output module 2.3b (c) 2002-2023 Volker Barthelmann and Frank Wille

error 89 in line 7 of "test.asm": macro redefinition
>abc     macro

 *  The terminal process "C:\Amiga\Crack\VenusTheFlytrap\BuildTest.bat" terminated with exit code: 1.

Originally Posted by phx

In the listing file? ... The expanded macro lines got a capital 'M' attached to their line number.

Of course. Can't belive I didn't think to look. Thanks.