Fails to find many symbols when compiling dcpu-cbmbasic

[unbibium]

When I compile the version of dcpu-cbmbasic tagged labelfails, the compiler failed to resolve many labels.

One of these errors was about the label NDX, which gave one error, even though it is referenced many times in the code. This suggests that it failed because it was referenced before it was defined, or before the file it was defined in was included. I can't really tell because the error doesn't give a file reference or line number itself. I did notice that io.dasm16 was the last file to be loaded, and it's where DEF_LOAD and similar labels are defined, and a lot of those gave errors too. So, maybe another pass needs to be added to the compiler to allow forward-references to other files.

[eva-knight]

Hmm, it should allow forward - referencing of labels and defines, it'll just not be able to optimise them (for the -1 to 31 thing). I'll probably go over the whole driver (handles files etc) thing when I look at DAsm again next week, so I'll do some tests and stuff then. If you figure out anymore I'd be interested to hear.

[unbibium]

I can work around this by combining all my sources into one file -- see the paultech-combined branch.

[eva-knight]

The weird thing is I think that's effectively what the driver does with includes. I'm free from exams soon so I'll try specifically getting your code to assemble with multiple files when I have some time.

[jameskirkwood]

I managed to get the labelfails version to assemble after a bit of fiddling. Here are the issues I came across:

• The whitespace trimmer does not remove carriage returns, resulting in trailing carriage returns on some tokens.
• The include expander in the driver does not treat carriage returns as whitespace, resulting in trailing carriage returns on file names not enclosed in quotes or angle brackets.
• Using regexEscape on macro arguments introduced backslashes in front of square brackets ([, ]) preventing evaluation.
• PICK n is unsupported. (replaced with [SP + n], as was done in paultech-combined)
• The DO_A macro in loadsave.dasm16 had a placeholder argument. (fixed in paultech-combined)

[paultech]

Hey guys,
We're tidying up the repos in prepration for a upcoming alpha. Can we get the latest on the issue? Anything required on our side?

[paultech]

@Yamakaky I removed your comment. Your emulator does not help us solve this issuse.

[Yamakaky]

Then tell me, don't remove it without notice...

[paultech]

Apologies, Just trying to keep issues and PR's clean of any offtopic discussion.

[jameskirkwood]

@paultech Some additional information regarding the issues I mentioned previously

• The whitespace trimmer does not strip carriage returns. (Dasm.cpp:25)
• The include expander does not strip carriage returns from the file name. (driver.cpp:64-65)

Including '\r' alongside space and '\t' in the whitespace strings on the lines referenced above fixes these issues. (Of course, it's not hard to avoid Windows line endings in the assembly for those who know the difference, but not everyone does.)

• A call to regexEscape is escaping [square brackets] in macro arguments. The macro argument, a, is never used in a regular expression and the backslashes prevent evaluation. (DAsm.cpp:911)
• The PICK n syntax is unsupported. (Vaasref's branch implements this.)

I am quite new to git and GitHub so do let me know if this is helpful.

[eva-knight]

I think the regexEscape was being used because "a" is passed as the fmt parameter for std::regex_replace, but yeah this doesn't actually seem to be anything like regex but rather to do with std::match_results::format so I'll update that correctly, and add an optional flags parameter to replaceString. If PICK n is the same as [SP + n], what I will do is make it so macros can be evaluated when used as arguments, and add that as a default macro.

[eva-knight]

I think I've fixed all the issues here except for the one relating to the driver code, so if you wanna see if my last commit on my branch fixes stuff that'd be great.

[jameskirkwood]

@Alfie275 I tested your branch with dcpu-cbmbasic (labelfails) and with some targeted test code.

The driver.cpp issue means include directives with Windows line endings fail (delimiters are irrelevant, contrary to my earlier comment) because the carriage return is treated as the final character of the file name. A conservative fix is to add '\r' to the set of stripped characters on line 65.

Since you removed the whitespace removal code from Instruction::LoadSource, whitespace-only strings sometimes make it into Program::Evaluate where it's passed to getNumber then stoi which throws (e.g. if a comma is followed by a quotation mark with a space in between). I fixed this temporarily by having Program::Evaluate trim whitespace before checking for an empty string (it currently trims after the check).

With the above fixes, and after fixing the macro syntax error I mentioned in my first comment, dcpu-cbmbasic (labelfails) assembles fine (and seems to execute properly).