NOTES file for SDCC pic16 port $Id$ Current pic16 port status is: Development Some things may change without notification between port updates. The latest SVN snapshot is guarenteed to compile without problems, but does not guarantee backwards compatibility. For any questions please ask the current port developers. Current developer: Raphael Neider Other people to contact: Vangelis Rokas Scott Dattalo ====================================================================== ====================================================================== 2006-Mar-14 Vangelis Rokas 1. Added enviroment variable 'PIC16_PACKED_BITFIELDS' which agressively packs bitfields in structures 2005-Mar-23 Vangelis Rokas 1. I have added some optimizations that are controlled via enviroment variables to allow checking. Later these will be either enabled globally or controlled by command line options. The variables are: a. OPTIMIZE_BITFIELD_POINTER_GET : optimizes bit field pointer reads b. NO_REG_OPT : there is no register optimization performed by pCode optimizer 2004-Oct-29 Vangelis Rokas 1. Function parameters are passed now all via stack. This might lower performance, but some issues are solved this way. Later we can enable passing through WREG,PRODL,PRODH,FSR0L by implementing specific pragmas 2004-Sep-27 Vangelis Rokas 1. Function parameters have been extended to cover functions with variable arguments. Now function parameters follow the rules below: a) void foo(long a, int b, char c) void foo(long a, int b, char c) reentrant Stack layout: c, b+1, b, a+3, a+2, a+1 and WREG = a b) prototype: void foo(long a, int b, ...) example: foo(0xaaffeedd, 0xbbcc, 0x4455, 0x7788); Stack layout: 0x77, 0x88, 0x44, 0x55, 0xbb, 0xcc, 0xaa, 0xff, 0xee, 0xdd WREG is not used in functions with variable arguments so that the address of the first parameter can be taken. 2004-Sep-24 Vangelis Rokas 1. Began implementation of generic pointers, current specs are: 0x0 xxxxxxx -> code pointer 0x8 xxxxxxx -> data pointer 0x4 xxxxxxx -> eeprom pointer (currently unimplemented) 2004-Aug-30 Vangelis Rokas 1. A few months ago Hans Dorn had the idea to support general pointer for accessing all code, eeprom data and data ram memory. These pointers would have 3 bytes of size (24-bits), of which only the 21 lower bits would be useful. The rest of them could be used to indicate the pointer type. I.e. 0x4xxxxxxx would mean code pointer 0x8xxxxxxx would mean eeprom pointer 0xcxxxxxxx would mean data ram pointer The implementatio of such pointers needs a lot of work and general reform of pointer access, data initializing functions and the writing of support functions for decoding their type. The implementation of such pointers along with the implementation of a more SDCC like stack access system will allow the writing of variable arguments functions like printf etc... Also one set of functions will be able to handle all data types without having to worry about where they are placed. 2004-May-23 Vangelis Rokas 1. The improvement of the port has been stalled a bit. But, struct/union SFR headers are ready for the PIC18F[45][45][28] chips along with their respective sources. 2. The genCmp function should be rewritten from scratch. 3. The internal helper functions for char/int/long/float arithmetic now compile and will be placed in the appropriate directory under device/ 2004-Feb-20 Vangelis Rokas Major update with many bugfixes. 1. The most of the pic16 regression tests (former pic regression tests) pass successfully. Many thanks to Hans Dorn who did a great job with the arithmetic, shift and pointer functions. 2. Bit fields now work properly. 3. Stack is permanently enabled. Command argument -pstack-enable is deleted and no more recognized by the port. 2004-Feb-07 Vangelis Rokas 1. Fixed a bug so that compiler allocated internal registered, will be shared along multiple sources via '.registers' section placed in absolute data memory address 0x0000. Registers 0x00 to 0x7f are considered as internal since they can be used for fast access. 2004-Jan-11 Vangelis Rokas 1. Compiling The current release of the port can produce object code which is not completely bug free. To use the new features the user should enable them via command line arguments. A sane set of command arguments that I use to test programs is: - debug options --debug enable sdcc debug information --debug-xtra enable pic16 port debug information (most useful) --debug-ralloc enable register allocator debug messages --pcode-verbose enable verbose pcode generator messages - port options --pno-banksel disable banksel directives for the assembler --pomit-config-words does not emit configuration instruction in the translation This is useful when copmiling multiple sources, when you do not want multiple config instructions in the end file --pomit-ivt disables the dumping of the interrupt vector tables in the translation for the same reasons as above --penable-stack enables stack support. This option uses stack to pass function arguments, and reuses registers between functions by saving the registers used in the function on the stack - compiler options --all-callee-saves you may omit this options as the port enables it by default, all functions are currently compiled as reentrant and they are marked as callee-saves --no-peep peephole optimizer is better to be switched off, because it behaves strangely in some cases --fommit-frame-pointer this omits frame pointer in functions that don't use registers (maybe changed later, not important) 2. Functions The current implementation puts every function in its own code section in PIC's program memory. This may not be the standard, but I think its more flexible. 3. Pragmas Since SDCC is goind for a release, its better to document pragmas available. 3.1. code The 'code' pragma emits a function's code at a specific address in program memory. Currently it is only used for functions. Syntax: #pragma code [function_name] [address] 3.2. stack The 'stack' pragma initializes the stack/frame pointer at an address of the data ram other than the default (which is the end of the available data ram) Synatx: #pragma stack [address] 3.3. maxram The 'maxram' pragma sets maximum data ram of the device. Currently is not used at all, but it may be useful in the future when devices with external memory will be supported. Syntax: #pragma maxram [max_address] 4. Internal compiler functions Internal SDCC functions like, __fsmul, etc... are currently supported by the port, but the libraries for the pic16 port are not yet ready. So one cannot use long and float variables. 5. Special Function Registers (SFRs) The processor SFRs are not anymore declared in any header file. The user can define by himself all the needed SFR's. The code to that is: sfr at [sfr_address] [sfr_name]; Where sfr_address is the SFR address in the data ram, and sfr_name is the name of the SFR. i.e.: sfr at 0xf80 PORTA;