# HG changeset patch
# User roug
# Date 1036101932 0
# Node ID 0e84dcd81835c53c09c9c5b9d855f74be8b714df
# Parent 1f4a17c1c56d2590a6e63142cf2a37fab2f68549
Several functions ready.
diff -r 1f4a17c1c56d -r 0e84dcd81835 docs/ccguide/basic09.appendix
--- a/docs/ccguide/basic09.appendix Thu Oct 31 22:05:32 2002 +0000
+++ b/docs/ccguide/basic09.appendix Thu Oct 31 22:05:32 2002 +0000
@@ -110,4 +110,95 @@
indicating that our C function worked!
+
+
+Example 2 - More Complex Integer Aritmetic Case
+
+
+
+
+
+Example 3 - Simple String Manipulation
+
+
+
+
+
+Example 4 - Quicksort
+
+The next example programs demonstrate how one might implement a
+quicksort written in C to sort some BASIC09 data.
+
+
+C integer quicksort program:
+
+
+#define swap(a,b) { int t; t=a; a=b; b=t; }
+
+/* qsort to be called by BASIC09:
+ dim d(100):INTEGER any size INTEGER array
+ run cqsort(d,100) calling qsort.
+*/
+
+qsort(argcnt,iarray,iasize,icount,icsiz)
+int argcnt, /* BASIC09 argument count */
+ iarrary[], /* Pointer to BASIC09 integer array */
+ iasize, /* and it's size */
+ *icount, /* Pointer to BASIC09 (sort count) */
+ icsiz; /* Size of integer */
+{
+ sort(iarray,0,*icount); /* initial qsort partition */
+}
+
+/* standard quicksort algorithm from Horowitz-Sahni */
+static sort(a,m,n)
+register int *a,m,n;
+{
+ register i,j,x;
+
+ if(m < n) {
+ i = m;
+ j = n + 1;
+ x = a[m];
+ for(;;) {
+ do i += 1; while(a[i] < x); /* left partition */
+ do j -= 1; while(a[j] > x); /* right partition */
+ if(i < j)
+ swap(a[i],a[j]) /* swap */
+ else break;
+ }
+ swap(a[m],a[j]);
+ sort(a,m,j-1); /* sort left */
+ sort(a,j+1,n); /* sort right */
+ }
+}
+
+
+The BASIC09 program is:
+
+
+PROCEDURE sorter
+DIM i,n,d(1000):INTEGER
+n=1000
+i=RND(-(PI))
+FOR i=1 to n
+d(i):=INT(RND(1000))
+NEXT i
+PRINT "Before:"
+RUN prin(1,n,d)
+RUN qsortb(d,n)
+PRINT "After:"
+RUN prin(1,n,d)
+END
+
+PROCEDURE prin
+PARAM n,m,d(1000):INTEGER
+DIM i:INTEGER
+FOR i=n TO m
+PRINT d(i); " ";
+NEXT i
+PRINT
+END
+
+
diff -r 1f4a17c1c56d -r 0e84dcd81835 docs/ccguide/chap2.chapter
--- a/docs/ccguide/chap2.chapter Thu Oct 31 22:05:32 2002 +0000
+++ b/docs/ccguide/chap2.chapter Thu Oct 31 22:05:32 2002 +0000
@@ -108,6 +108,47 @@
Compile Time Memory Allocation
+
+The following rules can serve as a rough guide to estimate how
+much memory to specify:
+
+
+
+The parameter area should be large enough for any anticipated
+command line string.
+
+
+The stack should not be less than 128 bytes and should take
+into account the depth of function calling chains and any
+recursion.
+
+
+All function arguments and local variables occupy stack space
+and each function entered needs 4 bytes more for the return
+address and temporary storage of the calling function's register
+variable.
+
+
+Free memory is requested by the Standard Library I/O
+functions for buffers at the rate of 256 bytes per accessed
+file. The does not apply to the lower level service request I/O
+functions such as "open()", "read()" or "write()" not to
+"stderr" which is always un-buffered, but it does apply to both
+"stdin" and "stdout" (see the Standard Library documentation).
+
+
+
+A good method for getting a feel for how much memory is
+needed by your program is to allow the linker to set the memory size
+to its usually conservative value. Then, if the program runs
+with a variety of input satisfactorily but memory is limited on the
+system, try reducing the allocation at the next compilation. If a
+stack overflow occurs or an "ibrk()" call returns -1, then try
+increasing the memory next time. You cannot damage the system by
+getting it wrong, but data may be lost if the program runs out of
+space at a crucial time. It pays to be in error on the generous
+side.
+