Assembler Addressing Error
pjv
Posts: 1,903
To PJ Monty;
I believe you are the person who would know how to fix this rater obscure assembler problem.
Last year while writing some good sized pieces of code, I occasionally had strange behaviour from the code. Re-assembling with test flags in the code·might make it go away, or just behave differently. After a LOT of frustrating investigation I came to the conclusion that under certain conditions·the assembler calculated the wrong address for a JMP instruction. While the listings look nearly correct,·certain assembler calculated addresses·were off by one, or under more obscure conditions, off by two or thee.
I have·finally narrowed this down to a very short piece of code where·one can make this occur at-will, and hence I hope you can find the culprit.
The conditions for this error to occur·are somewhat difficult to describe, but hopefully with the code snippit you can zero in on it.
In some of my·programs, I import blocks of already debugged routines, complete with their own variable definitions, so I may have variables declared at various locations, not all up-front, as is more typical.
When one has a·variable-bit-referencing-instruction such as·SETB, CLRB, SB, SNB, etc,·referencing a FORWARD_VARIABLE.X·(where FORWARD_VARIABLE is declared·further down in the code, and X is non-zero),·and this instruction·is subsequently (not neccessarily immediately) followed by an @JMP or @CALL·instruction then·all subsequent addresses calculated by the assembler are·in error; low by one location.
This does not happen when a PAGE instruction is used instead of the @ symbol, nor does it happen when the variable's bit "zero"·is referenced.
When the assembler subsequently encounters an ORG command, all following address calculations are again re-aligned and correct.
I realize that I have probably found an adequate work-around by using the less convenient PAGE command over the @ command, however with some of the new activity in the SX/B area, where many JMPs/CALLs are automatically compiled with a preceding @, some programmers my well be led down the proverbial garden path.
Besides, one is never sure if the source of this bug has also some other festering implications not yet or fully discovered, and it's best to track this puppy down and fix it properly.
I hope this description and the attachment is useful in localizing this bug.
Many thanks for your good work.
Peter (pjv)
(hope I can figure out how to attach the snippet)
I believe you are the person who would know how to fix this rater obscure assembler problem.
Last year while writing some good sized pieces of code, I occasionally had strange behaviour from the code. Re-assembling with test flags in the code·might make it go away, or just behave differently. After a LOT of frustrating investigation I came to the conclusion that under certain conditions·the assembler calculated the wrong address for a JMP instruction. While the listings look nearly correct,·certain assembler calculated addresses·were off by one, or under more obscure conditions, off by two or thee.
I have·finally narrowed this down to a very short piece of code where·one can make this occur at-will, and hence I hope you can find the culprit.
The conditions for this error to occur·are somewhat difficult to describe, but hopefully with the code snippit you can zero in on it.
In some of my·programs, I import blocks of already debugged routines, complete with their own variable definitions, so I may have variables declared at various locations, not all up-front, as is more typical.
When one has a·variable-bit-referencing-instruction such as·SETB, CLRB, SB, SNB, etc,·referencing a FORWARD_VARIABLE.X·(where FORWARD_VARIABLE is declared·further down in the code, and X is non-zero),·and this instruction·is subsequently (not neccessarily immediately) followed by an @JMP or @CALL·instruction then·all subsequent addresses calculated by the assembler are·in error; low by one location.
This does not happen when a PAGE instruction is used instead of the @ symbol, nor does it happen when the variable's bit "zero"·is referenced.
When the assembler subsequently encounters an ORG command, all following address calculations are again re-aligned and correct.
I realize that I have probably found an adequate work-around by using the less convenient PAGE command over the @ command, however with some of the new activity in the SX/B area, where many JMPs/CALLs are automatically compiled with a preceding @, some programmers my well be led down the proverbial garden path.
Besides, one is never sure if the source of this bug has also some other festering implications not yet or fully discovered, and it's best to track this puppy down and fix it properly.
I hope this description and the attachment is useful in localizing this bug.
Many thanks for your good work.
Peter (pjv)
(hope I can figure out how to attach the snippet)
Comments
Thank you for taking the time to isolate this problem and create a short piece of code that demonstrates it. I have downloaded your example code and will take a look to see what is going on.
Thanks, PeterM
This bug is now fixed. It will be released with other fixes/changes when the next update of the IDE is released. When will that happen? I have no idea, but it will happen.
Thanks, PeterM