6502.org

Posted: **Sat Sep 11, 2021 11:30 pm**

My project is getting quite large, and it can no longer fit in a main.s file with everything at global scope. I have started moving every module into its own scope, and it has made my code much more readable

Code: Select all

jsr player::move
jsr player::bullets::move
jsr player::shoot
jsr enemies::move

however, now I am running into a scope run-around. especially when modules use symbols or labels outside their scope. For instance, I cant include the player metasprite constant from my sprites module in the player module, because at that point my sprites module hasnt been defined yet. I am using explicit scope in these scenarios

Code: Select all

lda ::player::Y_H

as of now, all my .includes live in my main.s file (I know this is wrong). And i have to shuffle them around to make sure scopes exist before they are used. I've tried using a

Code: Select all

.if .define(module)

and then including that file in every file that uses it, but it doesnt seem to be working

In C, I would make a header file and declare these before I defined them so they can be used in other modules (right?) and include the header file whenever I needed it. I am not sure what is the """"right way"""" to do this in assembly, but I have a vested interest in doing this per-industry-standard as I begin searching for careers in the tech field. Any input or words of wisdom about program structure would be greatly appreciated

Posted: **Sun Sep 12, 2021 7:18 pm**

reesey-spoon wrote:

In C, I would make a header file and declare these before I defined them so they can be used in other modules (right?) and include the header file whenever I needed it. I am not sure what is the """"right way"""" to do this in assembly, but I have a vested interest in doing this per-industry-standard as I begin searching for careers in the tech field. Any input or words of wisdom about program structure would be greatly appreciated

What I do in ca65 (and this is the ca65 from the cc65 suite) is to have a header file for each program (.s) file and that's included in both the .s file and any other files that needs to access the symbols in that particular file. The keyword in the header file is .global which effectively says "export this symbol if defined in this file, or act as a placeholder in the object file to be resolved at link time"

So e.g.

Code: Select all

;********************************************************************************
;* strout.h:
;*      String print utility
;********************************************************************************

        .global _strout

Then in the strout.s file:

Code: Select all

;********************************************************************************
;* strout.s:
;*      String print utility
;********************************************************************************

        .macpack        generic

        .include        "rubyOs.h"
        .include        "osVectors.h"

        .include        "strout.h"

and in any other file that needs to call _strout:

Code: Select all

;********************************************************************************
; textUtil.s:
;       Utility text handling subroutines
;       Note: Underline functions are called from the standard osVectors
;       block at the top of memory
;********************************************************************************

        .macpack        generic

        .include        "hardware.h"
        .include        "keys.h"
        .include        "zeroPage.h"
        .include        "osVectors.h"
        .include        "strout.h"
        .include        "oHex.h"

        .include        "textUtil.h"

and so on.

I don't use scopes and the :: construct in my code at all, but this way lets me treat it as separately compiled modules in exactly the same way I separately compile C programs.

(I do use .proc and .endproc several times in the same file but merely as a way to keep labels separate between individual little subroutines. This works exactly the way defining a function does in C).

Hope that helps a little...

-Gordon

Posted: **Sun Sep 12, 2021 9:28 pm**

drogon wrote:

reesey-spoon wrote:

In C, I would make a header file and declare these before I defined them so they can be used in other modules (right?) and include the header file whenever I needed it. I am not sure what is the """"right way"""" to do this in assembly, but I have a vested interest in doing this per-industry-standard as I begin searching for careers in the tech field. Any input or words of wisdom about program structure would be greatly appreciated

What I do in ca65 (and this is the ca65 from the cc65 suite) is to have a header file for each program (.s) file and that's included in both the .s file and any other files that needs to access the symbols in that particular file. The keyword in the header file is .global which effectively says "export this symbol if defined in this file, or act as a placeholder in the object file to be resolved at link time"

Ok this helps. It seems like I can do it this way or just use .export and .import in each module. The thought of using .import and .export for all my metasprite constant names seems like a lot of work, so I may favor the way you are doing it. I could just not name all my metasprites / other array offset data, but I would like it to update in all locations if I change something.

I will play around with and see which one I prefer. using .export and .import will get rid of the :: naming scheme anyway, part of me just wants my code to look like

Code: Select all

player.move();
player.isHit();
blayer.bullets.move();

as much as possible. I am getting a little tired of naming every symbol as

Code: Select all

movePlayer: 
updatePlayerBullets:
moveEnemies:
updateEnemyBullets:
wasPlayerHit:

and so on.

The more I read, the more I am learning there isn't really a right way, just a way of greater convenience

Posted: **Sun Sep 19, 2021 7:22 am**

It's worth knowing that there's a ".autoimport" directive, which obviates the need for many .imports, though it has some caveats.

6502.org

scopes, modules, and symbols in ca65

scopes, modules, and symbols in ca65

Re: scopes, modules, and symbols in ca65

Re: scopes, modules, and symbols in ca65

Re: scopes, modules, and symbols in ca65