marienbad Posted March 27, 2021 Share Posted March 27, 2021 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? Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 28, 2021 Share Posted March 28, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted March 28, 2021 Share Posted March 28, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted April 3, 2021 Share Posted April 3, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
p1FqO3 Posted August 31, 2021 Share Posted August 31, 2021 (edited) 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. Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted August 31, 2021 Share Posted August 31, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
JeremiahK Posted September 1, 2021 Share Posted September 1, 2021 (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.) 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted September 1, 2021 Share Posted September 1, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted September 1, 2021 Share Posted September 1, 2021 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? 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.