@Bruce Abbot:
Yeah, seems like we agree on banksel. I think japanhalt is the nonbeliever.
Your last post has me all kinds of confused, though.
First off, I could not reproduce that error. Your code assembles fine on my version of MPLAB.
I assume "40000" represents SOME number to the IDE. I dont' even know what the default actually is, tbh. I always use "0x" or "." or "b'" etc. In my MPLAB (I suppose there could be options or differences between versions), there is no invalid number. If you exceed the max for the device's bank, it just wraps around. It doesn't even give me a warning when I turn off all warning suppression, even. The only warning I get is to make sure the proper bankbits are selected, because 4000 doesn't happen to wrap all the way back to bank0, apparently.
You say you don't need a line number because it jumps you to the line.
Here's is an example macro error that I just generated on my version of MPLAB:
#define myvar 4000
lsl16 macro aa
clrc
rrl aa,f
rrl aa+1,f
endm
;test code
lsl16 20h
nop
goto $-1
If I assemble that, it's fine. Now I add:
lsl16 myvar.TYPO.OOPS
And I get an error when I assemble it. Because I misspelled "myvar," in case you did not catch that.
Now, here's the rub.
In my error report, I get
Error[113] Z:\...\testcode.ASM 33 : Symbol not previously defined (MYVAR.OOPS.TYPO)
Error[113] Z:\...\testcode.ASM 34 : Symbol not previously defined (MYVAR.OOPS.TYPO)
Those are the
only two errors generated. If I click on them, they shoot me over to where I wrote the macro. This tells me I used the macro wrong somewhere...... BUT WHERE?
If I go into the .lst file, number 33 and 34 don't immediately mean anything to me. I finally find this:
00031 LSL16 MACRO AA
00032 CLRC
00033 RLF AA,F
00034 RLF AA+1,F
00035 ENDM
This was much work, because it seems all I have is 2 digits from the error list which match up to ONE of many sets of said numbers in the "line source code" column. Maybe it's cuz I dont know how to read the lst file and need to looks for something else... but don't worry, it gets much worse! Because even after finding it... it is MY definition of the macro. Which it just another kick in the nads.
I have to scan the entire lst file to finally find the error. And list files are huge. And finally after finding the needle in the haystack with zero help from the IDE, here it is, as shown in the lst file.
Error[113] : Symbol not previously defined (MYVAR.OOPS.TYPO)
0087 0D80 M RLF MYVAR.OOPS.TYPO,F
Error[113] : Symbol not previously defined (MYVAR.OOPS.TYPO)
0088 0D81 M RLF MYVAR.OOPS.TYPO+1,F
Even if the list is ONLY a few pages, this is still a PITA, to me. On a big project, the list file can be hundreds of pages. I don't call this hand-holding to want a bone, here, which there is so far absolutely none. The address given on the error report has NOTHING to do with where the error is. It only points to where I wrote the actual macro, itself.
Now, once I have found the actual error by physically scanning the entire LST file, it shows line number 87 in the code. So I go back to my code and enter this line number... and it takes me... somewhere in the vicinity but not even to the correct line. I have to scan about 10 lines back to find it (depending on how many macros you used, it could be a lot more dead space to scroll back... pages and pages.) This is AFTER scanning
the entire lst file just to find this line number.
If I wrote:
rrl typoooooooo,f
or maybe..
call subroutine.typooooooooooo
or even if I have to go through all the trouble to write this:
lcall subroutine.typooooooo
pagesel $
banksel xyz
and I try to assemble it, the error will link me right to the spot. It takes 5 seconds to recognize and fix my typo and hit "build." Clicky, typy, f10. Compare that to the game of "where's Waldo?" Now that I am going thru these motions, again, I recall doing these same tests, back when, after finally having enough and ripping out all my macros and wondering if perhaps I was just doing something wrong. I remember specifically being annoyed with this aspect of turning a minor typo into a major hassle. This why I have to wonder if there are settings on the IDE which you have used. I can't imagine never running into this exact thing and exercising the vocal cords with familiar 4 letter words. Now IF the error was in the last file you edited, you can cntrl + Z till something clicks.. make a mental note... cnrl+Y to put everything back. Then go back and fix the error. Or you can look thru the entire list file. You can dump all the work you just did and go back to an earlier revision. Or you can just take the macro out of the code in every instance where you used it, and never go thru this, again.
Also, now that I am thinking about it, again, the problem with macros using no parameters is that if you misspell the macro, you will create a label. There is no error. No color change in the text. Just an invisible error that your assembler can't find. You can use the indented label warning, I would think. Or you could use the IDE's jump to [label] and scan for your typo, assuming you didn't mess up the first couple of letters... But again, it's been years since I investigated this stuff, so whatever solutions I found, they were not satisfactory to me. I really rather have error than to have to keep my code free of all such warnings to even have a chance to notice this --- in fact indented labels are a tool I use, frequently, to make bookmarks. This is why peudoinstructions and assembler directives are fine to me but macros are to be avoided, wherever possible. (I concede there are instances where macros are worth the trouble; but you always have to be careful.)
Blue is good. Purple is bad.
I have come up with some truly inelegant subroutines to replace nice macros. Thinking more about it, it should be possible to use macros IN subroutines. Once that tests good, you are fairly solid as long as you are calling the subroutine in your future code. The assembler/IDE is the smart one in my partnership. With my bestest thinking cap on, all I do is create and fix errors. I'm not gonna go off the reservation, alone, unless I have to. I can see how macros are the best thing since sliced bread when your code is fairly short and legible. Short and legible do not describe assembly for long. Even modestly complex code will soon turn into a strand of DNA which is navigable only with the help of the IDE.