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