On Sat, Jun 23, 2012 at 12:25 PM, Gál Zsolt <tralitove...@freemail.hu>wrote:
> Examing the macros.inc file in sdcc/device/lib/pic14/libsdcc/regular,
> it can help to answer the question:
>
> ; -----------------------------------------------
> ; --- generic pointer access helpers
> ; -----------------------------------------------
>
> GPTRTAG_DATA EQU 0x00
> GPTRTAG_CODE EQU 0x80
>
> ; dispatch according to gptr type
> select_routine macro dataptr, codeptr
> ; __data pointer tag: 0x00
> xorlw GPTRTAG_DATA
> btfsc _STATUS, Z
> goto dataptr
> ; __code pointer tag: 0x80
> xorlw (GPTRTAG_DATA ^ GPTRTAG_CODE)
> btfsc _STATUS, Z
> goto codeptr
> endm
>
> I think pointers are 24 bit variables in the data memory ( register
> banks ) and according the highest bit ( 23 ) will decide this pointer
> is pointed a code memory location or a register file position.
Right.
> That is
> why I think that the __code modifier should be removed. If I give this
> modifier to a variable it means that the variable will be in program
> memory. But program memory isn't changeable.
>
The cinit_t structure members are read from the program memory, they are
never written. I still think that __code qualifier is ok.
Borut
> 2012/6/23 Borut Ražem <borut.ra...@gmail.com>:
> > I have an impression that __code acts oposite as intendend: if __code is
> > defined, then _cinit is assumed to be in data memory - see the generated
> asm
> > with BANKSELs, which is wrong.
> >
> > Omitting "__code" in line 71 is just a (ugly) workaround since "__code
> > cinit_t *cptr" seems to be correct: cptr IS a pointer to cinit_t
> structure
> > in code section.
> >
> > Has anybody investigated in which svn revision the bug appeared? If it
> was
> > really in rev. 7080, then it is an ugly side effect of optralloc branch
> > merge :-(
> >
> > I think this should be fixed ASAP, before the RC2 release, so any help is
> > welcome. Raphael, can you please take a look to this problem?
> >
> > Borut
> >
> >
> > On Sat, Jun 23, 2012 at 12:57 AM, Gál Zsolt <tralitove...@freemail.hu>
> > wrote:
> >>
> >> Here is a copy from idata.c:
> >>
> >> 70 unsigned num, size;
> >> 71 __code cinit_t *cptr;
> >> 72 __code char *src;
> >> 73 __data char *dst;
> >>
> >> I think *cptr is not takes place in code memory rather in data memory.
> >> So the __code modifier shouldn't be in line 71. I tried it, and it is
> >> working for me. The generated code is more beautiful:
> >>
> >> ; .line 76; "../idata.c" cptr = &cinit.entry[0];
> >> MOVLW high (_cinit + 2)
> >> MOVWF r0x1002
> >> MOVLW (_cinit + 2)
> >> MOVWF r0x1003
> >> MOVLW 0x80
> >> MOVWF r0x1004
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
