Menu ▾ ▴

#8 Question on "Using default destination of 0 (Access Bank)."

v1.0_(example)
closed
Molnár Károly
None
1
2015-02-17
2014-10-17
Diego Herranz
No

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!

Related

Support Requests: #8

Discussion

  • Diego Herranz

    Diego Herranz - 2014-10-17

    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.

     

  • Molnár Károly

    Molnár Károly - 2014-10-17
    • This message is new but the behaviour hasn't changed, right?

    It is just a warning message, the behavior has not changed. Warned that not specified the mode of bank access.

    • Do MPASM and GPASM have the same behaviour on this respect?

    No, to my knowledge the mpasmx no such wordy.

    • 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?

    This one are determined by the addresses of the SFRs.

    • To avoid these messages, should SDCC be more explicit? Or what should be done?

    To my knowledge the sdcc suppress the warnings of the gpasm.

    Károly

     

  • Molnár Károly

    Molnár Károly - 2014-10-19

    Sorry I didn't explained myself. Do they both try to guess if the register
    is in the access bank when the mode isn't specified? And do they both
    behave in the same way?

    Both compiler uses a default behavior.

    And how does it know in case of r0x00?

    This question will help decide the boundary of BSR. (Bank Select register)
    Of course only the case of the PIC18 series.

    if ((address < BSR_boundary) || (address >= (0xF00 + BSR_boundary)))
  {
  Use Access Bank
  }
else
  {
  Use BSR (Bank Select register)
  }

    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.

    When gpasm is automatically called from SDCC, this message is shown. Is it
    a SDCC bug?

    The gpasm the -q switch may cause shall not issue a warning. About this the sdcc is needed to provide for.

    Károly

     

  • Diego Herranz

    Diego Herranz - 2014-10-22

    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:

    $ gpasm -o blink_led.o -c blink_led.asm
blink_led.asm:280:Message[1301] Using default destination of 0 (Access Bank).
blink_led.asm:285:Message[1301] Using default destination of 0 (Access Bank).
blink_led.asm:287:Message[1301] Using default destination of 0 (Access Bank).
blink_led.asm:291:Message[1301] Using default destination of 0 (Access Bank).
blink_led.asm:295:Message[1301] Using default destination of 0 (Access Bank).

    Paying attention to line 280, on blink_led.lst you can see:

    6A??           00280         CLRF    r0x00

    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.

    $ gpasm -o blink_led_modified.o -c blink_led_modified.asm 
blink_led_modified.asm:280:Message[1301] Using default destination of 0 (Access Bank).
blink_led_modified.asm:285:Message[1301] Using default destination of 0 (Access Bank).
blink_led_modified.asm:287:Message[1301] Using default destination of 0 (Access Bank).
blink_led_modified.asm:291:Message[1301] Using default destination of 0 (Access Bank).
blink_led_modified.asm:295:Message[1301] Using default destination of 0 (Access Bank).

    I would expect a warning about line 280 saying something like "Using default destination of 1 (BSR)."

    Checking blink_led_modified.lst:

    6B00           00280         CLRF    0x300

    6B means CLRF using BSR so it looks correct.

    Is the warning message wrong? Is it a bug?

     
    blink_led.asm
    blink_led_modified.asm

  • Molnár Károly

    Molnár Károly - 2014-10-23
    • assigned_to: Molnár Károly
     

  • Molnár Károly

    Molnár Károly - 2014-10-23

    You're right, it is in this form is not good. Sometimes the message is misleading.

    I would expect a warning about line 280 saying something like "Using default destination of 1 (BSR)."

    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

     

  • Molnár Károly

    Molnár Károly - 2014-10-26

    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]

      0: Is the default. No strict messages.
  1: Show warning messages if one of is missing.
  2: Show error messages if one of is missing.

    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

  • Molnár Károly

    Molnár Károly - 2014-12-20
    • status: open --> closed
     

  • nyholku

    nyholku - 2015-02-17

    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.

     

Anonymous
Anonymous

Add attachments
Cancel