Since gputils 1.4.0, gpasm started to give messages like this:
seven_seg.asm:284:Message[1301] Using default destination of 0 (Access Bank).
On gputils 1.3.0, these messages weren't shown.
Questions:
- This message is new but the behaviour hasn't changed, right?
- Do MPASM and GPASM have the same behaviour on this respect?
- How does GPASM know that "access bank" mode must be used? For SFRs, it can guess it because of the register name but, for other GPRs?
- To avoid these messages, should SDCC be more explicit? Or what should be done?
Thank you very much for clearing my doubts!
Anonymous
More info:
gpasm says:
[...]
seven_seg.asm:284:Message[1301] Using default destination of 0 (Access Bank).
seven_seg.asm:286:Message[1301] Using default destination of 0 (Access Bank).
seven_seg.asm:289:Message[1301] Using default destination of 0 (Access Bank).
[...]
seven_seg.asm:
[...]
284 CLRF TRISB
285; .line 47; seven_seg.c LATB = 0; // LEDs off
286 CLRF _LATB
287 _00136_DS:
288; .line 50; seven_seg.c for(i=0; i<10; i++){
289 CLRF r0x00
[...]
It says the same for lines 284 and 289 but the former is a SFR and the latter a GPR.
It is just a warning message, the behavior has not changed. Warned that not specified the mode of bank access.
No, to my knowledge the mpasmx no such wordy.
This one are determined by the addresses of the SFRs.
To my knowledge the sdcc suppress the warnings of the gpasm.
Károly
Thanks for your fast reply.
On 17 Oct 2014 19:38, Molnár Károly molnarkaroly@users.sf.net wrote:
Thanks for your help!
Regards
Related
Support Requests:
#8Both compiler uses a default behavior.
This question will help decide the boundary of BSR. (Bank Select register)
Of course only the case of the PIC18 series.
The "BSR boundary" depends on the processor type. (This is typically 0x60 or 0x80 it used to be.) For example the data sheet of the PIC18F452, page 43.
The gpasm the -q switch may cause shall not issue a warning. About this the sdcc is needed to provide for.
Károly
Thank you very much Károly!
I will report to SDCC to "hide" these warnings.
Still one thing I don't understand which I don't know if it's a bug:
I have an asm file generated by SDCC. If I call gpasm I get:
Paying attention to line 280, on blink_led.lst you can see:
6A means CLRF using Bank select, so everything fine.
Now, I change line 280 in blink_led_modified.asm:
Before: 280 CLRF r0x00
After: 280 CLRF 0x300
Address 0x300 can't be accessed using access bank so let's see.
I would expect a warning about line 280 saying something like "Using default destination of 1 (BSR)."
Checking blink_led_modified.lst:
6B means CLRF using BSR so it looks correct.
Is the warning message wrong? Is it a bug?
You're right, it is in this form is not good. Sometimes the message is misleading.
It would not be good, because there is no banksel in front of the referenced instruction. This message must be corrected. Should be warned that there is no banksel directive. (In case you really there is no.)
So it seems never enough the testing.
Károly
There is a new command line option:
-S [0|1|2], --strict [0|1|2] Set the strict level of the recommended instruction-parameters (W or F and A or B). The "strict messages" have higher priority than the warnings. (See: -w [0|1|2]) [0]
I changed some messages.
svn [r1109]
gputils-src-20141026-1109.tar.gz
gputils-20141026-1109-setup.exe
Károly
Related
Commit: [r1109]
Last edit: Molnár Károly 2016-02-15
I'm still getting this message with:
~/sdcc-3.4.0/bin/sdcc -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.4.0 #8981 (Apr 5 2014) (Mac OS X i386)
published under GNU General Public License (GPL)
and
gpasm -v
gpasm-1.4.0 #1107 (Oct 28 2014)
Asking about this on the SDCC list did not produce any response on how to get rid of this…and I'm not seeing clear instructions here either.