X-Git-Url: https://git.gag.com/?a=blobdiff_plain;ds=sidebyside;f=src%2Fpic16%2FNOTES;h=16cfa6b41d3e6e6662dcb9a59085d6e4a7c567db;hb=6cb515b98c5977589446a39a6271958383d0a3da;hp=4d38a12d0abc9e6ddee7ab931484dcfb7b207873;hpb=02e5ffe7558a69ea0293fda3e1cf9747ac0ff29e;p=fw%2Fsdcc

diff --git a/src/pic16/NOTES b/src/pic16/NOTES
index 4d38a12d..16cfa6b4 100644
--- a/src/pic16/NOTES
+++ b/src/pic16/NOTES
@@ -4,20 +4,92 @@ $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
+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:
-Vangelis Rokas	<vrokas AT otenet.gr>
+Raphael Neider	<rneider AT web.de>
 
 Other people to contact:
+Vangelis Rokas	<vrokas AT users.sourceforge.net>
 Scott Dattalo	<scott AT dattalo.com>
 
 ======================================================================
 ======================================================================
+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