-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PASS pseudo opcode #49
Comments
How about a workaround...? I'm thinking something like you have a reference to a label that is ONLY defined inside the checking macro, and the macro only defines it when it actually succeeds. That is, the label definition is inside the "IF" condition. So when the checking macro initially fails, the label isn't defined - hence another pass will happen. Assembler will keep doing passes up to the maximum or until no undefined labels. No undefined labels means your checking macros are all happy (they have defined the labels that say OK). I haven't tried this, but maybe something like this would work for your use-case? |
Good idea. Here is my macro:
You can use it e.g. at the end of a table to make sure the table doesn't cross a page boundary. |
Perhaps worth posting in the "DASM CLUB"? |
Good Idea! But I still would like to have the pass number. 😄 |
Hm, after I switched from an old DASM version to the latest one, the macro doesn't create an error anymore. 😒 The labels are undefined, but DASM returns "complete". |
The current code LINE would be helpful in macros too. |
I think the cleanest solution here would be a new pseudo-op that will force another pass. If it doesn't stop getting triggered in later passes, dasm will naturally error-out the assembly. |
Also, you can get the pass number by sticking the following construct at the top of your assembly... |
I think it would be helpful to query the current pass number.
I have some checking macros (e.g. for code and data alignment) which often fail in the first passes and abort assembly. But in the final pass they would pass.
It would be even better if ERR (or a new pseudo op) would only stop assembling in the last pass.
The text was updated successfully, but these errors were encountered: