[Coco] Re: C compiler on OS-9 HOWTO?

Albert Stinger albertstinger24 at canada.com
Fri Mar 11 08:58:25 EST 2005


After looking over the "What You Should Know About Your
C Compiler.txt" found at RTSI archive.  I noticed it needed
some editing, so here is the edited version: Note* if anyone
finds additional editing errors please post new version here *

Albert Stinger.


October  1989        THE RAINBOW 82

Feature:

Getting started with cgfx functions and improving your system
with a fast compiler utility

What You Should Know About Your C Compiler
BY Numa David

The C compiler release predates the Color Computer 3. hard disk drives for 
the CoCo,
OS-9 Level II. and the Level II Development System with its vdd (RAM disk). 
Neither
the compiler nor the manual has been updated to achieve the high performance 
and
compiling speed possible with the new hardware or software.

While the C compiler was being written, the CoCo did not have sufficient 
disk space
to keep all the necessary files on one disk drive. The compiler was coded to 
look
for files in the DEFS and Lib directories on Drive /d1, and the manual 
stated that
the DEFS and LIB directories were on that drive.  Disk space limitation no 
longer
exists due to the recent improvements in hardware and software.

If your system has a 40- or 8O-track. double-sided floppy drive as /d0. your 
disk
has space for more files. The compiler can be patched to look for its DEF 
and LIB
directories there instead of on /d1, letting you keep all your system, 
commands
and compiler files on one disk. If your system has a hard disk drive, you 
may not
only keep all your files there but all file access including the compiler 
files.

Better yet. if your system includes the Level II Development System with the
vdd device driver (RAM disk), there are patches and procedures that give you
the high performance and speed of RAM-based compiling instead of disk-based
compiling.

The instructions that cause the compiler to look on Drive /d1 for the DEFS 
and LIB
directories are coded in the compiler files cc1 and c.prep. These files can 
be
patched to cause the compiler to look for the DEFS and LIB directories on 
any drive
you choose, including /r0 (vdd RAM disk) available with the Level II 
Development
System.

The remainder of this article guides you through steps necessary to optimize 
the
compiler to your system.  Some initial notes to remember are:

 . Perform the following on backup copies of your system and compiler disks.
          The system and compiler disks are modified, and it is possible for 
patch
          utilities to destroy important data on your disks.

 . Drive /h0 is used in some of the following examples. Substitute /d0 if
          your system does not include a hard disk drive.

 . The EZGen utility used is available from Burke & Burke, as advertised in
          THE RAINBOW. It is possible to use OS-9 commands (modpatch with 
os9qen OR
          cobbler) if you prefer; but, after considering the low price, the 
readers
          this will interest, and the inevitable complications that will be 
avoided.
          I concluded that EZGen is the practical choice for these examples. 
The
          objective here is to show you the simplest approach to a practical 
problem.


October  1989        THE RAINBOW 83

Compiler Patches

If you have a hard disk drive you can Patch a custom version of your 
compiler that
searches Drive /h0 for the DEFS and LIB Directories as follows:

 OS9: chd /h0/cmds
 OS9: ezgen c.prep
 l c.prep
 c 135c 68
 c 135d 30
 v
 q
 OS9: ezgen cc1
 l cc1
 c 0EE5 68
 c 0EE6 30
 v
 q

If you have a 40- or 80-track, double-Sided disk drive as /d0, you can patch 
a custom
version of your compiler that searches Drive /d0 for the DEFS and LIB 
directories as
follows:

 OS9: ezgen c.prep
 l c.prep
 c 135d 30
 v
 q
 OS9: ezgen cc1
 l cc1
 c 0EE6 30
 v
 q

If you have the OS-9 Level II Development System, your compiler can be 
optimized to run
at maximum speed using the vdd (RAM disk) as follows:

 Boot patches:

 To add the r0_192k.dd device descriptor to your boot file:

 OS9: ezgen os9boot
 b
 i /d1/modules/r0_192k.dd
 q

To set Default Drive /dd to /h0 (omit this if you don't have a hard disk 
drive):

 OS9: ezgen os9boot
 l dd
 u /d1/modules/h0
 q

You'll want to use the cgfx functions from your Level II Development System. 
They are
C graphics functions similar to the gfx and gfx2 functions in BASIC09. The 
manuals
furnished by Tandy fail to give the necessary instructions required to 
compile programs
with cgfx functions.

To compile cgfx functions rlink must be renamed c.link, and rma must be 
renamed c.asm as
follows:

 OS9: chd cmds
 OS9: del c.asm
 OS9: del c.link

Now let's rename the headers for the MODULES directory.

 OS9: ezgen rma
 l rma
 r c.asm
 q
 OS9: rename rma c.asm
 OS9: ezgen rlink
 l rlink
 r c.link
 q
 OS9: rename rlink c.link


October  1989        THE RAINBOW 84


The above patches, using EZGen, act directly on the disk files; you do not 
use os9gen
or cobbler. You simply reboot your system.

Note: Except for initial access to disk drives to move files to /r0 for 
compiling,
the above compiles and links entirely in RAM - the disk drives do not run.

Merging the Library Files

The following merged cgfx library files are also merged with your programs 
when they
are linked by the fast c.link procedure shown later.

 OS9: merge cgfx.l clib.l sys.l
 >merged.l

Include merged.l in the LIB directory. To ensure compatibility, be sure to 
use only
the new linker supplied with the Development System.

Preparing the Initializer

Use the editor to prepare cc1_init, a procedure file to initialize the fast 
compiler,
as follows:

 * cc1_init *
 iniz r0
 chd /r0
 makdir LIB
 chd LIB
 copy /h0/lib/merged.l merged.l
 chd /h0/defs
 dsave /h0 /r0 ! shell
 chx /h0/cmds
 load cc1
 load c.prep
 load c.pass1
 load c.pass2
 load c.asm
 load c.link

Setting Up the Fast Linker

Use the editor to prepare fast_link, a procedure file you can use to put 
specific
programs in for linking. Using a procedure file avoids typing a long list of 
commands
each time you recompile and relink your application.

The quantity of relocatable files merged below serves as only an example. 
The exact
quantity depends upon the number of programs linked to form your 
application. Here
is a typical procedure file:

 * fast_link *
 chd /h0/sources
 merge prog1.r prog2.r prog3.r >temp1
 merge prog4.r prog5.r prog6.r >temp2
 merge prog7.r prog8.r prog9.r >temp3
 merge temp1 temp2 temp3  >/r0/lib/
 prog.l

* The following compiler line links the      *
* CGFX functions in merged.l to your program *

c.link cstart.r -l=prog.l -l=merged.l -o=prog

This completes preparation of the system for fast compiling. Reset your 
computer
and reboot.

To Use Your Fast Compiler:

Compile each of the source programs of your group of source programs to a 
relocatable
object file as follows:

 . Initialize the fast compiler by typing at the OS9 prompt:
   OS9: cc1_init

 . Copy the program to /r0:
   OS9: chd /r0
   OS9: copy /h0/sources/prog.c prog.c

 . Compile the program.
          OS9: cc1 prog.c -ro

 Note. Debug and recompile if errors occur during compiling.

 . Copy the program back to /h0:
   OS9: copy proq.r /h0/sources/prog.r
   OS9: del prog.r
   OS9: del prog.c

You now have a group of relocatable object files that must be linked to form 
an
executable object file as follows:

To Use Your Fast Linker:

To link the group of relocatable files to an executable object file, simply 
type
at the OS9 prompt:

 OS9: fast_link

If fast_link produces errors, debug the offending source program, delete the
offending relocatable file, and repeat the compiler steps above. The
executable program is saved in the CMDS directory. To run the program type
at the OS9 prompt:

 OS9: prog

Summary

The keys to this fast compiler are the patches that cause the compiler to 
look
for DEFS and LIB directories on /r0 instead of /d1 and keeping the compiler
commands loaded in memory for immediate execution instead of loading from
disk drives.

Beyond that, many approaches and variations are possible for setting up the
system for fast compiling. Enhancements and improving convenience and 
utility
will undoubtedly occur to you. You can develop a completely interactive,
menu-driven, fast compiler utility.

C Graphics Library

Now for the C graphics library. Your C compiler has available a new graphics
library that expands the original C library to a state-of-the-art graphics
programming language. C language graphics library functions similar to the
gfx2 functions in BASIC09 are provided on the OS-9 Level II Development
System disk as cgfx functions for the C compiler. You will want to use
your cgfx commands.

However, essential steps required before using cgfx with the compiler are 
not
included in the manual - the kind of steps that probably never occur to even
experienced programmers. The following gives you the information needed to 
get
started with cgfx functions.

Use of cgfx functions requires a Color Computer 3 with the following 
software:
OS-9 Level II Operating System. OS-9 Level II Development System. C compiler
and C library, and Multi-Vue. (You can use cgfx functions without Multi-Vue.
but your cgfx documentation is in the Multi-Vue manual.)

If you haven't compiled a program using cgfx functions yet, the following 
will
spare you some time, frustration and confusion:

Pages 10-1 and 10-2 of the Multi-Vue manual advise you to link the cgfx 
library
along with other libraries to your C program, and give instructions along 
with
a command line example (that does not work yet) as follows:

 OS9: cc1 prog.c -r
 OS9: c.link /d1/lib/cstart.r prog.r
        -l=/d1/lib/cgfx.l -l=/d1/lib/clib.l
        -l=/d1/lib/sys.l -o=prog

How frustrated a programmer can get if no one tells him that the cc1 and 
c.link
modules used above are not the ones that came with the compiler and do not 
work
until they are changed. You can't be expected to know this because it's not 
in
the manual. Tandy knows about this specific problem - and one of its capable
technical representatives will explain it if you call Tandy's Fort Worth
headquarters. But how long does a programmer troubleshoot a command line 
example
before he resorts to that? (Have a heart. Tandy - we need addenda for this 
one.)

The manual fails to advise that the old c.link and c.asm must be deleted 
from
the CMDS directory, and that r.link must be renamed c.link and rma must be
renamed c.asm before using the compiler with the above command line as 
follows.
(Warning: Perform the following on a backup disk. Important compiler modules
will be changed.)


October  1989        THE RAINBOW 85


It is assumed the rma and r.link commands from the Development System disk 
as
well as c.asm and c.link from C compiler disk, are on commands directory on
Drive /d0.

 OS9: chd /d0/cmds
 OS9: del c.asm c.link
 OS9: rename r.link c.link
 OS9: rename rma c.asm

Now you are ready to proceed according to the instructions and examples on
Page 10-2 of the Multi-Vue manual However, I suggest first merging the 
library
files as follows, assuming the library files from the Development System 
disk
are in the LIB directory on /d1:

 OS9: chd /d1/lib
 OS9: merge cgfx.l clib.l sys.l
        >merged.l

Keep merged.l in the LIB directory. The rather long linker line above can be
shorten in all future call as follows, provided your source code is on a
directory named SOURCES on /d0 and the LIB and DEFS directory are on /d1:

 OS9: chd /d0/sources
 OS9: cc1 prog.c -r
 OS9: c.link .d1/lib/cstart.r prog.r
        -l=/d1/lib/merged.l -o=prog


Debugging Your Manual

It may save you more time and confusion to know the manual contains errors
in some cgfx command line examples. The following, from Page 10-21 of 
Multi-Vue,
will help you debug your manual.

 SetGc (path,grpnum,bufnum)  Wrong
        SetGC (path,grpnum,bufnum) Right

If you are uncertain about path simply use 1 to indicate standard output.

I don't know how many cgfx command line errors are in the manual, but when
(not if) you run into other cases where everything seems OK but you get an
Unresolved References Error, you can determine whether the command from the
manual is correct by using rdump as follows:

To dump system command headers to your screen using rdump from the
Development System:

 OS9: chd /h0/lib
 OS9: rdump cgfx.l -a

or

To produce a printout so you can compare all the cgfx commands on the system
disk with all the cgfx commands in the manual:

 OS9: rdump cgfx.l -a >/p

The information in the dump you are interested in has the exact spelling of
the command in question, including uppercase, lowercase, underscores, etc.
as listed under "global symbols defined." If the spelling from the dump 
differs
from the manual, use the spelling from the dump and note the correct command 
in
the manual. Otherwise you will find gfx functions to be as simple,
straightforward and useful as their BASIC09 counterparts.

These functions are fundamental to graphics programming in the C language.
CoCo users are fortunate that Tandy chose an industry standard, 
state-of-the-art
operating system, languages and powerful features such as cgfx for the Color
Computer. You don't want to do without them.

Numa David, an architect and planning consultant, uses a CoCo 3 to process
demographic and other data into graphic output for feasibility studies for
contemplated real-estate development projects. He is currently writing a
full-featured CAD (Computer-Aided Design > application in the C language
for the CoCo 3.

(Questions or comments concerning this article may be addressed to the 
author
at 5305 Grand Lake. Bellaire. TX 77401; (713) 664-9529. Please enclose an 
SASE
when requesting a reply.) 






More information about the Coco mailing list