The ".cinit" section, as somebody already posted, is generated
automatically by the compiler to be used as a template to initialize all
the compile-time initialized variables.
The initialization code reads this table and copies the values to their
in-RAM locations.

Now I'm trusting my memory, but if I remember it right the table is
organized as a series of chunks with starting RAM address, length and
payload. At the very beginning of the table there is a long integer with
the number of chunks that follow.

Thus, it makes sense that a program that uses no compile-time
initialized variables end with four bytes equal to zero in the ".cinit"
section, it is the number of chunks of initialization data present.
That long must be there because usually the initialization code is
always linked, irrespectively if the program has initialized variables
or not.


Isaac



Em 19/8/2012 08:03, alan.b.pearce@stfc.ac.uk escreveu:
>> It looks to me like you're disassembling unprogrammed memory. The org
>> commands are leaving gaps of unprogrammed memory. When you disassemble
>> it, it shows whatever op-code corresponds to all ones.
> That disassembles to the ADDLW 0xFF that you see following the highlighte=
d lines in the picture. Not sure what opcode RETLW 0 is, bit I get the impr=
ession it is being used as a filler by the linker to cause some sort of cra=
sh if the code goes AWOL.
>
>>> I can see now what you mean. (see attached picture)
>>>
>>> Tamas
>
>

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.