* device/lib/pic16/startup/crt0i.c (_cinit): local variables where
[fw/sdcc] / src / pic16 / NOTES
1 lNOTES file for SDCC pic16 port
2 $Id$
3
4 Current pic16 port status is: Development
5
6 Some things may change without notification between port updates. The latest
7 CVS snapshot is guarenteed to compile without problems, but does not
8 guarantee backwards compatibility.
9
10 For any questions please ask the current port
11 developers.
12
13 Current developer:
14 Vangelis Rokas  <vrokas AT users.sourceforge.net>
15 Raphael Neider  <rneider AT web.de>
16
17 Other people to contact:
18 Scott Dattalo   <scott AT dattalo.com>
19
20 ======================================================================
21 ======================================================================
22 2004-Oct-29 Vangelis Rokas
23 1. Function parameters are passed now all via stack. This might
24 lower performance, but some issues are solved this way. Later
25 we can enable passing through WREG,PRODL,PRODH,FSR0L by implementing
26 specific pragmas
27
28
29 2004-Sep-27 Vangelis Rokas
30 1. Function parameters have been extended to cover functions with
31 variable arguments. Now function parameters follow the rules below:
32
33   a) void foo(long a, int b, char c)
34      void foo(long a, int b, char c) reentrant
35
36 Stack layout: c, b+1, b, a+3, a+2, a+1 and WREG = a
37
38   b) prototype: void foo(long a, int b, ...)
39
40         example: foo(0xaaffeedd, 0xbbcc, 0x4455, 0x7788);
41
42 Stack layout: 0x77, 0x88, 0x44, 0x55, 0xbb, 0xcc, 0xaa, 0xff, 0xee, 0xdd
43
44 WREG is not used in functions with variable arguments so that the address
45 of the first parameter can be taken.
46
47
48
49
50 2004-Sep-24 Vangelis Rokas
51 1. Began implementation of generic pointers, current specs are:
52         0x0 xxxxxxx -> code pointer
53         0x8 xxxxxxx -> data pointer
54         0x4 xxxxxxx -> eeprom pointer (currently unimplemented)
55
56
57 2004-Aug-30 Vangelis Rokas
58 1. A few months ago Hans Dorn had the idea to support general pointer
59 for accessing all code, eeprom data and data ram memory. These pointers
60 would have 3 bytes of size (24-bits), of which only the 21 lower bits
61 would be useful. The rest of them could be used to indicate the pointer
62 type. I.e.
63 0x4xxxxxxx would mean code pointer
64 0x8xxxxxxx would mean eeprom pointer
65 0xcxxxxxxx would mean data ram pointer
66
67 The implementatio of such pointers needs a lot of work and general
68 reform of pointer access, data initializing functions and the writing
69 of support functions for decoding their type.
70
71 The implementation of such pointers along with the implementation of
72 a more SDCC like stack access system will allow the writing of variable
73 arguments functions like printf etc... Also one set of functions will be
74 able to handle all data types without having to worry about where they
75 are placed.
76
77
78 2004-May-23 Vangelis Rokas
79
80 1. The improvement of the port has been stalled a bit. But, struct/union
81 SFR headers are ready for the PIC18F[45][45][28] chips along with their
82 respective sources.
83
84 2. The genCmp function should be rewritten from scratch.
85
86 3. The internal helper functions for char/int/long/float arithmetic
87 now compile and will be placed in the appropriate directory under device/
88
89
90
91 2004-Feb-20 Vangelis Rokas
92 Major update with many bugfixes.
93
94 1. The most of the pic16 regression tests (former pic regression tests) pass
95 successfully. Many thanks to Hans Dorn who did a great job with the
96 arithmetic, shift and pointer functions.
97
98 2. Bit fields now work properly.
99
100 3. Stack is permanently enabled. Command argument -pstack-enable is deleted
101 and no more recognized by the port.
102
103
104 2004-Feb-07 Vangelis Rokas
105
106 1. Fixed a bug so that compiler allocated internal registered, will
107 be shared along multiple sources via '.registers' section placed
108 in absolute data memory address 0x0000. Registers 0x00 to 0x7f are
109 considered as internal since they can be used for fast access.
110
111
112
113 2004-Jan-11 Vangelis Rokas
114
115 1. Compiling
116 The current release of the port can produce object code which is not
117 completely bug free. To use the new features the user should enable them via
118 command line arguments. A sane set of command arguments that I use to test
119 programs is:
120
121 - debug options
122         --debug         enable sdcc debug information
123         --debug-xtra    enable pic16 port debug information (most useful)
124         --debug-ralloc  enable register allocator debug messages
125         --pcode-verbose enable verbose pcode generator messages
126
127 - port options
128         --pno-banksel   disable banksel directives for the assembler
129         --pomit-config-words    does not emit configuration instruction in
130                         the translation This is useful when copmiling
131                         multiple sources, when you do not want multiple
132                         config instructions in the end file
133         --pomit-ivt     disables the dumping of the interrupt vector tables
134                         in the translation for the same reasons as above
135         --penable-stack enables stack support. This option uses stack to
136                         pass function arguments, and reuses registers between
137                         functions by saving the registers used in the function
138                         on the stack
139
140 - compiler options
141         --all-callee-saves      you may omit this options as the port
142                         enables it by default, all functions are currently
143                         compiled as reentrant and they are marked as
144                         callee-saves
145         --no-peep       peephole optimizer is better to be switched off,
146                         because it behaves strangely in some cases
147         --fommit-frame-pointer  this omits frame pointer in functions that
148                         don't use registers (maybe changed later, not
149                         important)
150
151
152 2. Functions
153 The current implementation puts every function in its own code section in
154 PIC's program memory. This may not be the standard, but I think its more
155 flexible.
156
157 3. Pragmas
158 Since SDCC is goind for a release, its better to document pragmas available.
159
160 3.1. code
161 The 'code' pragma emits a function's code at a specific address in program
162 memory. Currently it is only used for functions.
163 Syntax:
164 #pragma code [function_name] [address]
165
166 3.2. stack
167 The 'stack' pragma initializes the stack/frame pointer at an address of the
168 data ram other than the default (which is the end of the available data ram)
169 Synatx:
170 #pragma stack [address]
171
172 3.3. maxram
173 The 'maxram' pragma sets maximum data ram of the device. Currently is not
174 used at all, but it may be useful in the future when devices with external
175 memory will be supported.
176 Syntax:
177 #pragma maxram [max_address]
178
179
180 4. Internal compiler functions
181 Internal SDCC functions like, __fsmul, etc... are currently supported by the
182 port, but the libraries for the pic16 port are not yet ready. So one cannot
183 use long and float variables.
184
185
186 5. Special Function Registers (SFRs)
187 The processor SFRs are not anymore declared in any header file. The user can
188 define by himself all the needed SFR's. The code to that is:
189
190 sfr at [sfr_address] [sfr_name];
191
192 Where sfr_address is the SFR address in the data ram, and sfr_name is the
193 name of the SFR. i.e.:
194
195 sfr at 0xf80 PORTA;