| ??? 04/17/03 02:10 Read: times |
#43582 - RE: Use of a non-unique label directive? Responding to: ???'s previous message |
Joe Kimbriel:
If you fall into the habit of programming short jumps and branches with $+3 and $-6 type you are for sure going to get caught MORE THAN ONE TIME, in one of several ways. The first is that you will sometimes count wrong and you only discover this after you have setup a whole debug cycle. I find that it takes a fraction of the time to create a unique label than is does to setup a whole debug cycle. Second there will for sure be times when you go and add or delete lines of code between the $ location and the $+6 location. This raises the amount of work becasue not just the modified lines must be edited but also the $+yuck lines as well. And how many times will one forget to make the latter change or catch it during the editing session? And then third, there is the oblique problem that occurs when you program several different processors using quite different tool sets. You can confuse yourself with the idea as to whether the $ refers to the base address of the current instruction OR if it refers to the address of the next instrution. Thus I recommend, as well as most other seasoned assembly language programmers that I have come to know over the many years, that it is the best to use unique labels in source code and just not use the $+yuck or $-ick syntax. Michael Karas |
| Topic | Author | Date |
| Is there a non-unique label directive? | 01/01/70 00:00 | |
| RE: Is there a non-unique label directive? | 01/01/70 00:00 | |
| RE: Is there a non-unique label directive? | 01/01/70 00:00 | |
| RE: Is there a non-unique label directive? | 01/01/70 00:00 | |
| Use of a non-unique label directive? | 01/01/70 00:00 | |
| Reason to use non-unique label | 01/01/70 00:00 | |
| RE: Use of a non-unique label directive? | 01/01/70 00:00 | |
| RE: Use of a non-unique label directive? | 01/01/70 00:00 | |
RE: Use of a non-unique label directive? | 01/01/70 00:00 | |
| RE: Is there a non-unique:Erik | 01/01/70 00:00 |



