changeset 565:0e84dcd81835

Several functions ready.
author roug
date Thu, 31 Oct 2002 22:05:32 +0000
parents 1f4a17c1c56d
children 3339ee2e58bc
files docs/ccguide/basic09.appendix docs/ccguide/chap2.chapter
diffstat 2 files changed, 132 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- 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!
 </para>
 </section>
+
+<section>
+<title>Example 2 - More Complex Integer Aritmetic Case</title>
+<para>
+</para>
+</section>
+
+<section>
+<title>Example 3 - Simple String Manipulation</title>
+<para>
+</para>
+</section>
+
+<section>
+<title>Example 4 - Quicksort</title>
+<para>
+The next example programs demonstrate how one might implement a
+quicksort written in C to sort some BASIC09 data.
+</para>
+<para>
+C integer quicksort program:
+</para>
+<programlisting>
+#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 &lt; n) {
+          i = m;
+	  j = n + 1;
+	  x = a[m];
+	  for(;;) {
+	       do i += 1; while(a[i] &lt; x);  /* left partition */
+	       do j -= 1; while(a[j] &gt; x);  /* right partition */
+	       if(i &lt; 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 */
+     }
+}
+</programlisting>
+<para>
+The BASIC09 program is:
+</para>
+<programlisting>
+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
+</programlisting>
+</section>
 </appendix>
--- 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 @@
 <title>Compile Time Memory Allocation</title>
 <para>
 </para>
+<para>
+The following rules can serve as a rough guide to estimate how
+much memory to specify:
+</para>
+<orderedlist>
+<listitem><para>
+The parameter area should be large enough for any anticipated
+command line string.
+</para></listitem>
+<listitem><para>
+The stack should not be less than 128 bytes and should take
+into account the depth of function calling chains and any
+recursion.
+</para></listitem>
+<listitem><para>
+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.
+</para></listitem>
+<listitem><para>
+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).
+</para></listitem>
+</orderedlist>
+<para>
+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.
+</para>
 </section>
 </section>
 </chapter>