Symbol definition issues - Case sensitivity in macro parameters, assigning address type variables

[svallee-dev]

When I build my code that contains ".ifdef", I'm getting an error message:

Symbol "true" is not defined.

So at the top of my main.a file that contains all my project included files, I make sure to define them myself, like so:

        true = 1        ; Needed by the compiler to handle .ifdef
        false = 0       ;   for some reason

Which allow me to build fine. I would assume these two symbols wouldn't have to be defined by the source code.

[informedcitizenry]

Can you share a snippet of your code? I am not able to reproduce this issue. If I run this

THEBOOL         = true

                .ifdef THEBOOL
                    lda #0
                .else
                    lda #56
                .endif

I get the expected output (lda #0)

[svallee-dev]

I responded by email, but I'm thinking maybe the proper way is to write an answer here in the thread. So here it is:

I wrote a tiny project to repro it, but could not. It built just fine. I tried to repro as closely to my real project as possible, but no success. So instead I started cutting down my real project, until I got to a mere few files, while still getting the build error. I zipped and attached it to this post.

Just assemble src/main.a and that should do it. If you don’t get the error, then maybe it’s a problem that’s specific to my computer.

First64.zip

[informedcitizenry]

thanks I'll take a look

[informedcitizenry]

I just released a new version. Can you re-try with that? A couple of things to be aware of:

Both the constants "true" and "false" are reserved words, so you will need to comment the lines out where you define them. Also, a recent change was made to how the preprocessor processes semicolon line comments. If the comment contains a colon, the parser interprets that to be a new line. This is in keeping in line with the behavior of other 6502 assemblers. Your source contains semicolon comments with colons in several places, such as line 92 of "general_macros.a". You can either change the semicolons into C-style "//" comments, or if you don't want to change your source you can give the new command line option "--ignore-colons"

On Sun, Jul 5, 2020 at 9:55 PM svallee-dev notifications@github.com wrote:

I responded by email, but I'm thinking maybe the proper way is to write an answer here in the thread. So here it is:

I wrote a tiny project to repro it, but could not. It built just fine. I tried to repro as closely to my real project as possible, but no success. So instead I started cutting down my real project, until I got to a mere few files, while still getting the build error. I zipped and attached it to this post.

Just assemble src/main.a and that should do it. If you don’t get the error, then maybe it’s a problem that’s specific to my computer.

First64.zip https://github.com/informedcitizenry/6502.Net/files/4876556/First64.zip

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/informedcitizenry/6502.Net/issues/1#issuecomment-653988646, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGRJ5S4NHDE7OUMSSWDLMELR2E4LDANCNFSM4NJGLJVA .

[svallee-dev]

Ok I updated my project with your new code, at the same time removing all my previous custom changes, and added the "--ignore-colons" flag and... it worked! Everything built fine!

... except that when I try to build a second (and more time) I then get these errors:

vblank.a(113,1): error: Symbol "true" is not defined.
vblank.a(133,1): error: Symbol "true" is not defined.
gameloop.a(13,1): error: Symbol "true" is not defined.
gameloop.a(23,1): error: Symbol "true" is not defined.

Now, a little context is needed: I'm not running the 6502.Net code from a command line, in which the entire runtime state would be reset every time it is run. Instead, the code is run inside a persistant iOS app. I make sure to recreate a fresh new state every time I assemble, but I noticed in the code there's quite a few static data. I'm wondering if that data linger around after a first assembly, causing issues on subsequent assembling.

This is how I invoke 6502.Net every time:

                // Assemble
                var compiler = new C64Hub.Compiler(project);
                if (compiler.IsReady)
                {
                    compiler.Assemble();
                }

That C64Hub.Compiler class is mostly:

    public class Compiler
    {
        public bool IsReady { get; private set; }

        AssemblerBase cpuAssembler = null;
        AssemblyController controller = null;

        public Compiler(Project project)
        {
            Assembler.Initialize(GenerateProjectArgs(project));

            if (Assembler.Options.CPU.Equals("z80"))
            {
                Assembler.BinaryFormatProvider = new Z80FormatProvider();
                cpuAssembler = new Z80Asm();
            }
            else
            {
                if (Assembler.Options.Format.Equals("d64"))
                    Assembler.BinaryFormatProvider = new D64FormatProvider();
                else
                    Assembler.BinaryFormatProvider = new M6502FormatProvider();
                cpuAssembler = new Asm6502();
            }
            controller = new AssemblyController(cpuAssembler);

            IsReady = (cpuAssembler != null && controller != null);
        }

        public void Assemble()
        {
            if (!IsReady)
            {
                throw new Exception("Not ready to assemble.");
            }
            controller.Assemble();
        }

I'm going to investigate if any static data in 6502.Net doesn't get reset properly. But hopefully you already have an idea of what's going on :)

[informedcitizenry]

Ahh! I see, your use case is slightly different. I honestly never thought of using this app in such a context, only a one-run kind of scenario. My assumption is that the static Assembler initialization is tied to construction of some of the main classes, like the Evaluator, the Options class, and the SymbolManager. You may have to implement some sort of state reset.

[svallee-dev]

Oh wow I just realized I posted in the wrong bug thread my previous responses.. sorry about that!

But I think both can be closed now!

[svallee-dev]

This was resolved. Thanks!