Is there an equivalent of "#pragma once" in RGBASM (Gameboy DMG assembly language)?

Question

So I am really just starting out in my assembly coding adventure. I have a little bit of knowledge of C/C++ but nothing too advanced yet.

But I also used to do a tiny bit of Z80 assembly, and I wanted to make some original Game Boy games (kind of a life-long ambition which is now just a fun hobby instead).

I have a working program which shows sprites and background etc. However I am trying to separate it into two or more assembly source files. And I ran into a problem of "constants.inc is already included". I managed to overcome it by simply not including "constant.inc" in my main.asm and then moving the "player.asm" include to the top. But this probably isn't the best way to handle it, it could get very complicated with multiple files.

Until now I have taken for granted the magic #pragma once line in C++.

How would you handle circular dependencies in ASM?

(Currently I am using RGBASM)

(I.e. I have files "constants.inc", "hardware.inc", "player.asm", "main.asm"; both asm files need access to both of the inc files. Main needs access to Player.asm but not the other way around)

Answer 1

Assembly language is typically not providing any safety nets or harnesses - so, in general, the answer would be "no". Assembly language is also not in any way standardized, especially in the area of assembler directives - so, even if there were some specific assemblers that supported such constructs, it certainly would not be generally true.

There might be workarounds that use conditional assembly in some specific assemblers that allowed you to mimic the

 #ifndef INCLUDE_GUARD
 #define INCLUDE_GUARD

 ......

 #endif

construct you might know from C, however. My assembler suports something like

 GENIF    include-guard = 0
 SETNUM   include-guard 1

 .......

 ENDGEN

That does exactly the same thing - YMMV.

From comments:

rgbasm apparently allows conditional assembly with

IF !DEF(guard)
  DEF guard 
  / … / 
ENDC

which more or less does the same.

An alternative could be to run assembly files through a C preprocessor (cpp actually doesn't normally care a lot what it pre-processes and will only look at preprocessor directives). That way you could even use #pragma oncein your assembly files.

Answer 2

Hard to give a definite answer without seeing the real structure. Even more as 'assemblers' isn't a singular language. each is different. A link to it's documentation would be very helpful and in what configuration (command line?) compilation is done.

From your write up it's possible to assume the whole project is not split in modules, assembled separate and linked later, but assembled as one source file into one object file. This structure is often the case with simple/beginner projects. Here every source file, no matter how you name it, is included into the assembled source at the point its 'include' statement is placed. Thus including the same 'header' in different files is producing an error.

Most C projects in contrast are build with each source file compiled separate and linked later on. Thus includes in one source file do not collide with the same include in any other.

The same can be done of course with assembler (*1). Assemble each of your source files into s distinct object module and link them at the end. That way each is handled at its own and no duplicates arise.

---

In your case this would look mean

• Compile MAIN.ASM and PLAYER.ASM separate using the RGBASM tool
  • Each including all definition files needed.
• Link them into an executable using RGBLINK

Since each is a distinct compilation unit, no error arise and no hacks are needed to avoid multiple inclusion.

Of course, since these are now separate compilation units, access between them must be granted, as by default an Assembler treats everything in a separate unit as private to this unit. So if there's for example an init function named SetupPlayer within PLAYER.ASM, then access to this must be allowed to external by exporting that entry point via an EXPORT directrive

     EXPORT SetupPlayer

...

SetupPlayer: ...

Usually all exports get placed on a single line and near the start of a source file to improve readability.

Now that function can be used from MAIN.ASM without further action (*3)

     CALL SetupPlayer

The whole point is to support separate compilation and linking while providing private name spaces.

---

That, or take into account that your source is a single item spread over different files and structure it accordingly - like include everything into a main file - only there and only once (*3).

---

*1 - C's capability of separate compilation is based on the object and link structure provided by its assembler base, so no difference if used right.

*2 - This is specific to RGBASM, which treats all unknown symbols as external. Other Assemblers may need some IMPORT or EXTERN directive, essentially creating a system of contracts, further enhancing encapsulation.

*3 - Naa, don't do there. Use the tools as intended, don't build 'hacks' to emulate separate compilation by some hack around includes. That is not only bad style, but a great way to introduce future issues - hard to solve issues.

Answer 3

Assemblers generally read all of the source files in a project two or three times. The first time will be used to define symbols. When targeting platforms where the size of an instruction will depend upon operand values, a second pass may be used to recompute symbols in case code got smaller. Then a final pass will be used to actually generate the output, using the symbols computed in the earlier pass or passes. As a result, circular dependencies would rarely pose a problem unless the shrinking of code in the middle pass would allow what would have been a long branch to become a short one; such situations may be rectified either by explicitly telling the assembler to use a short jump in a place that will end up being a short branch (the assembler would squawk if it wasn't a short branch on the final pass), or else telling the assembler to use more than three passes. At least one assembler I used allowed programmers to request an arbitrary number of passes, since could contrive a program which would take dozens of passes, each with one more branch getting shrunk, thus allowing a branch just before it to also shrink, but in practice I've never needed more than three.