• AVR Freaks

Hot!pagesel and subsequent call

Author
LaoMa
Starting Member
  • Total Posts : 38
  • Reward points : 0
  • Joined: 2017/08/01 21:39:42
  • Location: 0
  • Status: offline
2020/05/24 22:43:00 (permalink)
0

pagesel and subsequent call

Hello,
I am a little odd, I have not been able to find a clear reply about this and reading the PIC data sheet has not given the certainty about it.
The question is: having the asm code, called in C by void Entry(void)   
_Entry:   
   PAGESEL _x
   call    _x
   PAGESEL $
   PAGESEL _y
   call _y
   PAGESEL $
   return
are both "PAGESEL $" mandatory? for a clearer code the reply should be "yes", but I could save 2 ROM locations.....
 
Thanks for any advise
Maurizio
#1

8 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28324
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: pagesel and subsequent call 2020/05/24 22:45:46 (permalink)
    +1 (1)
    Neither of the "PAGESEL $" lines are required.
    You could save another one too if you knew _x and _y were in the same code segement (which would force them to be in the same page).
    Once you get rid of the last "PAGESEL $", you can also convert the second "call" into a GOTO, and therefore remove the "return" as well.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    LaoMa
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/08/01 21:39:42
    • Location: 0
    • Status: offline
    Re: pagesel and subsequent call 2020/05/24 23:00:06 (permalink)
    0
    Hello Ric, 
    thanks, you are ever kind.... I have a story as asm programmer but my past was the Z80 and a TMS32 RISC long time ago......Smile: Smilesad: sad
     
    ric
    Neither of the "PAGESEL $" lines are required.

    Ok, I have supposed but having had a look to the .lst output from the XC8, I have found that every call in C has the PAGESEL before and ever after. I know that's the correct form, now I suppose it can be optimized with levels higher than 2 by the compiler.
     
    ric
    You could save another one too if you knew _x and _y were in the same code segment (which would force them to be in the same page).

    That's I have known, unfortunately they aren't!
     
    ric
    Once you get rid of the last "PAGESEL $", you can also convert the second "call" into a GOTO, and therefore remove the "return" as well.

    Nice to know, but I cannot do that, that subroutine is called by C, then better let the compiler to deal with segments and addresses.
     
    Maurizio
    #3
    ric
    Super Member
    • Total Posts : 28324
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: pagesel and subsequent call 2020/05/24 23:18:09 (permalink)
    +1 (1)
    LaoMa
    ...
    Ok, I have supposed but having had a look to the .lst output from the XC8, I have found that every call in C has the PAGESEL before and ever after. I know that's the correct form, now I suppose it can be optimized with levels higher than 2 by the compiler.

    The "PAGESEL $" is required to select the current page before you can execute a GOTO within the current page.
    It's entirely redundant if the very next thing you are going to do is another PAGESEL.
     
    LaoMa
    ric
    Once you get rid of the last "PAGESEL $", you can also convert the second "call" into a GOTO, and therefore remove the "return" as well.

    Nice to know, but I cannot do that, that subroutine is called by C, then better let the compiler to deal with segments and addresses.

    The compiler will set the required page before calling your assembly code, and I don't thini it will make any assumption about what page is selected when you return.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    LaoMa
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/08/01 21:39:42
    • Location: 0
    • Status: offline
    Re: pagesel and subsequent call 2020/05/24 23:22:02 (permalink)
    0
     
    The compiler will set the required page before calling your assembly code, and I don't thini it will make any assumption about what page is selected when you return
     
    It does, if I remove the last PAGESEL $, the linker returns errors....
    Removing the other, the code is 1 shorter!wink: wink
     
    post edited by LaoMa - 2020/05/24 23:25:00
    #5
    ric
    Super Member
    • Total Posts : 28324
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: pagesel and subsequent call 2020/05/24 23:28:25 (permalink)
    +2 (2)
    What sort of errors does the linker return?
    I am amazed the linker would know.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #6
    LaoMa
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/08/01 21:39:42
    • Location: 0
    • Status: offline
    Re: pagesel and subsequent call 2020/05/25 01:13:53 (permalink)
    0
    this one:

    Memory Summary:
        Program space        used   F71h (  3953) of  1000h words   ( 96.5%)
        Data space           used   11Ah (   282) of   200h bytes   ( 55.1%)
        EEPROM space         None available
        Configuration bits   used     2h (     2) of     2h words   (100.0%)
        ID Location space    used     0h (     0) of     4h bytes   (  0.0%)
    "Calculating checksum"
    make[2]: *** [dist/Offset/production/BAT_PB_V3.4.production.hex] Error 4
    make[1]: *** [.build-conf] Error 2
    make: *** [.build-impl] Error 2
    nbproject/Makefile-Offset.mk:362: recipe for target 'dist/Offset/production/BAT_PB_V3.4.production.hex' failed
    make[2]: Leaving directory 'C:/Users/Administrator/MPLABXProjects/BAT_PB_V3.4'
    nbproject/Makefile-Offset.mk:91: recipe for target '.build-conf' failed
    make[1]: Leaving directory 'C:/Users/Administrator/MPLABXProjects/BAT_PB_V3.4'
    nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
    BUILD FAILED (exit value 2, total time: 14s)
     
    #7
    1and0
    Access is Denied
    • Total Posts : 11125
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: pagesel and subsequent call 2020/05/25 08:21:36 (permalink)
    +2 (2)
    LaoMa
     
    Nice to know, but I cannot do that, that subroutine is called by C, then better let the compiler to deal with segments and addresses.

    I think you may have a misunderstanding here. Anyway, replace your routine in Post #1 with this:
    _Entry:
            pagesel _x
            call    _x
            pagesel _y
            goto    _y

     
    #8
    LaoMa
    Starting Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/08/01 21:39:42
    • Location: 0
    • Status: offline
    Re: pagesel and subsequent call 2020/05/25 23:31:16 (permalink)
    0
    Hello Ric, 
     
    yes, I have understood your trick, with "goto" you use the return instruction of the jumped sub to go back at the original calling.grin: grin
    In any case, while apparently everything works fine at the beginning, there is something odd: after some minutes, the SW does  strange behaviors, going in place that should not due by the code flow. I can suppose is because I put the asm into the main.c, using #asm directive (with asm() instruction is the same).... and it needs the "psect code" directive before the assembler instruction. I dunno if that's the cause of such mis-behavior, I have no time to investigate deeper the listing .... not now! 
     
    Then, because what I need is to read a version of the combined .hex file, I put there a retlw VERSION instruction at myAddress  and I closed this issue just putting in my project
    global _Xcall 
    _Xcall EQU myAddress
    in the .asm file I have already, and declaring the prototype
    extern uint8_t Xcall(void);
    in the main.h.
    Then the call in main.c  is: 
    Ycall(Xcall());
    and that's working fine.
    It takes 2 instructions more than the pure assembler code, but it is enough to be fit in the ROM, that did not have space for reading the location with indirect addressing or readword function in memory.c 
     
    In any case, thanks for your suggestions.....
     
    Maurizio
     
     
    #9
    Jump to:
    © 2020 APG vNext Commercial Version 4.5