On Thu, 25 Jul 1996, Steve Hardy wrote: > > From: NEIL GANDLER > > 2. When refining my code, I eliminate all assembling errors, but I I find it more productive, at least in the long run, to track these down as soon as they appear. If it's really spurious, figure out how to shut it up, but "testing" code that contains errors that can be detected by the assembler seems really pointless. > > still have quite a few assembler messages. They mostly are the following: > > > > Arugment out of range. Least significant bits used. > > > > This message occurs, almost everytime I try modifying the > > tris registers or the option register and a few others. I have tried > > assuring that I only move an 8-bit equivalent and nothing more. > > This message sometimes also occurs when using the BSF and BCF commands. > > Yes, this is usually acceptable. It occurs when accessing registers > defined in bank 1 because their 'address' is over 127. Don't worry, > just ensure that your code is setting status.rp0 appropriately so that > the device is really accessing the second bank. "Don't worry, be happy" is, unfortunately, about all you can do here, yes. The idea of trapping such errors was a good one, but it hasn't been taken nearly far enough in Microchip's assembler to be useful. Working with what's available, it would be at least a little bit better to mask the address so as to eliminate the warning. Best of all would be something a bit smarter, and I've implemented a set of macros to manage this, but I'm far too unhappy with the result to wish to share it in ts current form. Last time I was involved in a discussion of this I think I was misunderstood just a little bit. It's almost certainly impossible to guarantee correct automatic determination of the setting of the register page select bit(s) at assembly time, but that wasn't what I was suggesting. It seems to me that a considerable assistance - say, about as useful, but less cumbersome, than the macro hackery I've been using - in keeping track of the settings would be easy to add, and with modest additional effort it could become a lot better. I don't expect that it will be perfect, and some manual "hinting" will certainly be necessary, but based on actual experience in a non-trivial project I gotta tell y'all, getting it right MOST of the time without manually tracing the code is worth a lot of development time. My experience may be biased a bit by the way the design kept shifting as the rest of the design team dreamed up new hoops for the firmware to jump through and discarded old ones, but I expect that's not too uncommon. It was during the revision of code that the checking the macros provided was most often called upon to catch an oversight in fiddling the page bits. > The same message may occur if you try to set the '9th bit' of a register > e.g. BSF my_reg,8. This is a worry, becasue you probably are making > use of an equate for the bit number which is all awry. The above example > would actually set bit 0 (the LSB) since there ain't no 9th bit in an > 8 bit register! And that's the other reason I hate the idea of "just ignoring" these warnings: they aren't really spurious, they're just set off far too often by perfectly okay code. But unlike the ugly but (nearly always) harmless sprinkling of (void) on every function used as a procedure in order to get lint to shut up (sorry, C roots showing there), mechanically adding a mask to register addresses to shut this up is likely to turn off the only diagnostic of a serious and easily-committed error. Only warning, that is, aside from "it doesn't work". :-(