Question about XREF vs XDEF (vasm 1.8 vs vasm 1.9)

[roondar]

I've run into a small problem when upgrading from vasm 1.8l to vasm 1.9d. In my code, I've so far used the following rules for .i files and .asm files:

• In the .i file for a .asm file, put a bunch of XREF <function> definitions for linking with other files
• In the .asm file, have no XREF or XDEF, but do have an include .i file for the same .asm file
• In other files that need to link against those routines, use include .i

In vasm 1.8 and below, this works and seems to be the only way it works other than defining the functions using XDEF in the .asm file itself (which seems really rather ugly to me).


In vasm 1.9d this no longer works and gives errors like "external symbal <name> must not be defined". So the questions I have are twofold:

1. What is the correct way to define functions in an .i include file (that is also included the the corresponding .asm file as it'll contain not just function definitions but also constants/structures etc) such that both vasm 1.8l and vasm 1.9 understand it?
2. Why has the definition of XREF/XDEF changed in 1.9d? Was the way it was working for all these years a bug?

Reason for asking is that I've spread quite some source over the years and I'd prefer to know how to change it so that it will work across both older and newer versions of the assembler (and hopefully on other assemblers as well).

[hooverphonique]

I suspect this could be due to my post here.

Let's see if phx steps in with a solution - he didn't say in the linked thread if he added a flag for this to enable previous behavior or not.

Otherwise you could use a technique similar to shared library includes where the include file defaults to import the symbol (xref) if some preprocessor symbol isn't defined, and export (xdef) if it is defined - you would then define the preprocessor symbol when you build the file that defines the symbols in the include file.

[a/b]

Originally Posted by roondar

...defining the functions using XDEF in the .asm file itself (which seems really rather ugly to me).

Ugly, but that's the correct way :P.

So if I understand this correctly, you are only using XREFs, and vasm is able to deduct that if any of those symbols are found it automatically "generates' corresponding XDEFs to export them?

If you want to use the same file for both your build and user build, I'd do similar to what I do in c/c++. When you are building the code, define a symbol e.g. BUILD_XXX and then in your .i files:

XDEFREF MACRO
  IFD BUILD_XXX
    XDEF \1
  ELSE
    XREF \1
  ENDC
  ENDM

XDEFREF myfn1
XDEFREF myfn2
...

[roondar]

Originally Posted by a/b

Ugly, but that's the correct way :P.

Wow, learn something new every day - but not all you learn makes you happy I suppose

So if I understand this correctly, you are only using XREFs, and vasm is able to deduct that if any of those symbols are found it automatically "generates' corresponding XDEFs to export them?

I don't know if it generates anything, up to now my workflow has been:

Put XREF's to all routines from an .asm file in a .i file (together with the rest of the interface such as structure definitions & constants), include the .i file in the .asm file it references and then include the .i file in every file that uses the routines from said object/asm file.

I'm 100% certain I didn't think this method up by myself, but I don't remember where I first saw it being used.

If you want to use the same file for both your build and user build, I'd do similar to what I do in c/c++. When you are building the code, define a symbol e.g. BUILD_XXX and then in your .i files:

XDEFREF MACRO
  IFD BUILD_XXX
    XDEF \1
  ELSE
    XREF \1
  ENDC
  ENDM

XDEFREF myfn1
XDEFREF myfn2
...

I'm not entirely certain that would fix the issue, but it's worth a try I suppose. Thanks anyway
Edit: actually, that probably works, although I might want to change it a bit for my purposes.

[meynaf]

Normally there is public keyword that can replace both xref and xdef. PhxAss supports it, its successor probably should as well.

[hooverphonique]

Originally Posted by meynaf

Normally there is public keyword that can replace both xref and xdef. PhxAss supports it, its successor probably should as well.

vasm mot syntax supports the public keyword, AFAIK.

[roondar]

Originally Posted by meynaf

Normally there is public keyword that can replace both xref and xdef. PhxAss supports it, its successor probably should as well.

I tried this out and it works. Thanks for the help
Now to start changing some code and re-uploading it...

[phx]

Originally Posted by hooverphonique

Let's see if phx steps in with a solution - he didn't say in the linked thread if he added a flag for this to enable previous behavior or not.

With flag I referred to an internal symbol-flag, not to a command line option.

Roondar's experience is completely my fault, because I implemented

xdef

and

xref

both lazily with the same code, like a

global

or

public

directive. This works with legal code, of course, but it allows illegal usage of these directives, which Roondar unfortunately exploited. Maybe others did that too and I'm sorry about that.

Fortunately hooverphonique finally made me fix it. So the current behaviour is now 100% compatible with all other assemblers.

Originally Posted by hooverphonique

vasm mot syntax supports the public keyword, AFAIK.

Yes. This will work as before, and uses the same code as xdef/xref did before. But note, that this is not a common 68k assembler directive. It is unknown to Devpac, for example.

So, if you want to write portable 68k source, I would stick to xdef/xref.

[roondar]

Originally Posted by phx

This works with legal code, of course, but it allows illegal usage of these directives, which Roondar unfortunately exploited. Maybe others did that too and I'm sorry about that.

Heh... To be fair, I exploited it without knowing it was an exploit. Made perfect sense to do it this way to me and my flawed brain

Yes. This will work as before, and uses the same code as xdef/xref did before. But note, that this is not a common 68k assembler directive. It is unknown to Devpac, for example.

So, if you want to write portable 68k source, I would stick to xdef/xref.

That's a good point. I'll try for a more portable solution. Thanks for the info!