[Color Computer] [coco]Getting started in C programming....

[Gene Heskett]

On Wednesday 11 January 2006 21:03, George Ramsower wrote:
>How would I go about understanding how to write in C?
>
>I have a tough time understanding the diffferent processes (OS-9
> C)that are required to make a finished program to actually do
> something!

This is largely because the C language is bigger than the memory 
addressing abilities of the coco if its not broken up into job category 
sized pieces.

c.prep: (my edition 19 only, don't even think about the microware if 
your src code exceeds 12k in text size & even then it has issues) is 
the program that gathers it all together into one data stream to be fed 
on toward the rest of the compilers pieces.

ansifront: processes this data stream, converting fully ansi styles of 
code into something the pre-ansi compiler itself can build.

c.pass1: does some pre processing of this data stream.

c.pass2: converts the output of c.pass1 into the assembly language that 
does the program.

c.comp: if you can find it, does this all in one pass.  Coco3's & level 
2 only IIRC.

c.opt: does peephole optimizations of this code.
c.opt2: does some small further optimizations on the assembly stream.
CnoY: (for coco3's & os9 level 2 only) optimizes away the use of the Y 
register, saving a clock cycle everytime it does this.

c.asm/r.asm/rma/whatever its called today: convert the assembly source 
from the above into linkable object code.

c.link/r.link then link it all into executable programs by pulling in 
the various c.lib/trig.lib/kreider.lib etc stuff, getting the code for 
the C function calls from the libraries and adding that to the 
executable stream, adding the addresses to the branch/jump calls that 
c.asm etc left blank, making the whole thing into a self contained, 
standalone executable(s), sometimes of considerable size.  rzsz-3.36 is 
around 34 kilobytes for each piece, although much of the code is common 
between the rz and sz.

>Is there someplace I can look to find out what it is that I am doing
> when I try to put together a simple routine?
>
>Thanks,
>
>George
>
While there have been several gigatons of paper wasted on C books, after 
spending probably $500 or so on them, only 2 really stand out, and they 
aren't really tutorials.  Thats the pair of C manuals by Kernigan & 
Ritchie themselves.

They are a pair of comparatively thin paperbacks, describing the 
language pre and post ANSI C, in what has to be the best examples I've 
seen of clear and concise to the point of extreme brevity, definitions 
of the language that all other so-called C manuals both expand on and 
supply examples of.  The second edition, ISBN 0-13-110362-8 [PBK],  and 
possibly Herbert Schildt's "C, The Complete Reference", ISBN 
0-07-881263-1, should be on every programmers overhead shelves.

All the others are very limited scope books that have a tendency to try 
and impress the writers coding style on the reader.  Sometimes this is 
good, but do keep the salt shaker handy when reading what they like to 
promote as the "gospel according to whomever's name" is on the spine.  

I think the only other one I got anything out of was Plum/Brodie (yeah, 
that Brodie, he wrote the original Forth language) Efficient C, which 
try's to show how small, efficient code is written, but its all based 
on only quasi-ansi C compilers that existed on dos/winderz boxes in the 
day it was written.  The principles are ok, but the code examples given 
won't build on our compiler very often.  Possibly there are newer, more 
applicable books available today, so grab a chair and read a while in 
your local B&N/Waldenbooks etc.  But don't waste $50 on a tome just 
because its 2+ inches thick, you won't get your monies worth out of 
many of them.

C, per sie, is a stack based language in that all local variables that a 
function might need access to when its called, are placed on the stack 
before the branch is executed, with access to them, and any values they 
may return, all accessed via offsets from the functions instant value 
of the stack pointer.  Other languages also share this basic premise as 
its an easily understood way to do position independant code, something 
the 6x09 cpu's naturally shine at, and which the intel/amd stuff took 
another 4 generations of silicon to even approach getting it right.

Globally accessable variables are generally accessed via offsets from 
the U register IIRC.  This keeps variables of local scope and variables 
of global scope well seperated as the local stuff disappears after the 
function has returned to the caller and it has disposed of the data 
returned and the stack pointer is then reset to invalidate that data 
area and make that memory available to the next function that might 
need it.

There is far more than this of course and I'm not a guru by any means, 
but those are the salient details, an overview, as I understand them.

Much is made of the 'position independant code' that will need to be 
understood when coming in from the rsdos environment, os9 lives on it 
and that to me, is the huge difference between codeing in asm for 
rsdos, and coding for asm in os9.
-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.


Brought to you by the 6809, the 6803 and their cousins! 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ColorComputer/

<*> To unsubscribe from this group, send an email to:
    ColorComputer-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/