--- /dev/null
+NOTES file for SDCC pic16 port
+$Id$
+
+Current pic16 port status is: Development
+
+Some things may change without notification between port updates. The latest
+CVS snapshot is guarenteed to compile without problems, but does not
+guarantee backwards compatibility.
+
+For any questions please ask the current port
+developers.
+
+Current developer:
+Vangelis Rokas <vrokas@otenet.gr>
+
+Other people to contact:
+Scott Dattalo <scott@dattalo.com>
+
+
+
+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
+ --pgen-banksel enable banksel directives for the assembler
+ This will be turned on by default later, but left as
+ is for now
+ --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;
projects / fw / sdcc / blobdiff