On Sat, Jun 23, 2012 at 12:25 PM, Gál Zsolt <tralitoverin@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.razem@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 <tralitoverin@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