No Illegal Opcodes Message from Dasm and Compile makes text file?

[marienbad]

With some code I compiled (mostly gotten from online) Dasm says, at the end of the long list:

 

NO_ILLEGAL_OPCODES       0000 ????         (R )
 

So obviously I get what it means but why warn about it?

 

Also, occasionally Dasm will compile something okay, but it has the text file icon and when I click it it opens in my text editor and there is nothing there, but compilation says everything okay?

 

[+Andrew Davie]

13 hours ago, marienbad said:

With some code I compiled (mostly gotten from online) Dasm says, at the end of the long list:

 

NO_ILLEGAL_OPCODES       0000 ????         (R )
 

So obviously I get what it means but why warn about it?

 

Also, occasionally Dasm will compile something okay, but it has the text file icon and when I click it it opens in my text editor and there is nothing there, but compilation says everything okay?

 

As to the last bit, let's see what you're entering to get dasm to compile.

That will give us the output filename, and we can proceed from there.

 

As to the first bit, that's not a warning - it looks like a label as shown in the symbol table.  It is referenced, and has a value of 0.

As always with these things, you can get better quality answers if we know exactly what you're doing, and have sample source code to test.

[+Andrew Davie]

You need to open the resultant binary in an emulator like Stella.

Unless you have the file association setup, then your system may treat it as a text file.

Let's get the assembly process going properly first.  Meanwhile, make sure you have Stella installed.

 

[JeremiahK]

As for the first part of your question, that's usually because you included macro.h, which defines its macros in one of two ways: with illegal opcodes, or without.  You can define a variable named NO_ILLEGAL_OPCODES to tell macro.h to use the legal-opcodes-only versions, otherwise it uses the illegal versions.  (You can look through the file macro.h to see how this is done.) If you don't define this variable, DASM will complain about it not existing, but everything will still compile just fine.

Edited April 3, 2021 by JeremiahK

[p1FqO3]

Is it possible to allow illegal opcodes, but also get rid of the "Unresolved Symbol" message?

macro.h uses IFNCONST to test for NO_ILLEGAL_OPCODES.

IFNCONST documentation says "Is TRUE if the expression result is undefined, FALSE otherwise".

I expected to be able to set -DNO_ILLEGAL_OPCODES=0 but, based on my understanding of the IFNCONST documentation, I believe that would still return FALSE, and thus not use illegal opcodes, since NO_ILLEGAL_OPCODES is "defined" even though it's set to a "falsy" value.

Edited August 31, 2021 by p1FqO3
Logic word changes. Double negative logic has my head spinning.

[JeremiahK]

Technically, I guess you could just edit your copy of macro.h so it says something like "IF NO_ILLEGAL_OPCODES == 1" and "IF NO_ILLEGAL_OPCODES == 0", and then define NO_ILLEGAL_OPCODES as one or the other, but it's not really necessary.

 

From the current dasm manual, page 39, 6.4.1:

Quote

 

Is TRUE if the expression result is defined, FALSE otherwise and no error is generated if the expression is undefined.

I have an older version of dasm, but the solution may be as simple as upgrading to the latest version.

[JeremiahK]

(I updated my dasm, and it still mentions NO_ILLEGAL_OPCODES as an unresolved symbol, but that's not really a problem.  It's better to be informed, while knowing it's not a problem, than to not know if it actually is a problem.)

[+Andrew Davie]

4 hours ago, JeremiahK said:

(I updated my dasm, and it still mentions NO_ILLEGAL_OPCODES as an unresolved symbol, but that's not really a problem.  It's better to be informed, while knowing it's not a problem, than to not know if it actually is a problem.)

This one is a bit of a special-case.  Yes, it's an unresolved symbol but technically it's not referenced (in a way that requires resolution to a value) so it isn't an error. It is reported as part of the symbol table (correctly) as a symbol which has not been resolved, but which is not preventing successful assembly. In my opinion, it belongs in the symbol table exactly as shown, dasm is doing exactly the right thing.
 

 

 

[Mr SQL]

15 hours ago, JeremiahK said:

Technically, I guess you could just edit your copy of macro.h so it says something like "IF NO_ILLEGAL_OPCODES == 1" and "IF NO_ILLEGAL_OPCODES == 0", and then define NO_ILLEGAL_OPCODES as one or the other, but it's not really necessary.

 

From the current dasm manual, page 39, 6.4.1:

I have an older version of dasm, but the solution may be as simple as upgrading to the latest version.

 

11 hours ago, JeremiahK said:

(I updated my dasm, and it still mentions NO_ILLEGAL_OPCODES as an unresolved symbol, but that's not really a problem.  It's better to be informed, while knowing it's not a problem, than to not know if it actually is a problem.)

Agree 100% therefore be careful about updating dasm, there's been a shift in perspective with the new release starting to turn some warnings into show stopping fatal errors that stop the binary from compiling, understanding it would break existing code (possibly your code).

 

I think design considerations should cater to the programmer being informed while knowing it's not a problem like you stated.

 

@Andrew Davie recently espoused treating every single warning as an error in an academic exercise for PlusCart development after expressing similar design sentiments and then having an epiphany to escalate the warnings to errors. 

 

There are clearly some different schools of thought on the subject,  I abstracted the three tiny BASIC error types from DASM compilation with What handled as a non-fatal warning designing SuperCharger BASIC:

 

How - syntax error code cannot compile

What - ignored as warning/non-fatal error

Out of memory - code cannot compile

 

Here's an example of these errors from my SillyVenture 2020+1 KC OS demo compilation that exhibits a real error under PlusCart and UnoCart but works fine on the real hardware; the fatal error is happening only on the platform where developer design philosophy has shifted to treat warnings as errors; perhaps it's best to leave warnings as warnings but know about them to keep the focus on real errors?