Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!nic.MR.NET!eta!com50!pwcs!stag!daemon
From: to_stdnet@stag.UUCP
Newsgroups: comp.sys.atari.st
Subject: Sozobon C
Message-ID: <719@stag.UUCP>
Date: 10 Feb 89 19:46:06 GMT
Sender: daemon@stag.UUCP
Lines: 81

From: thelake!steve@stag.UUCP (Steve Yelvington)


Two would-be Sozobon C users, markr@resrch and
hofer@lan.informatik.tu-muenchen.dbp.de, posted questions:

> From: markr@resrch.UUCP
> Subject: Sozobon C - best setup?
> 	Recently I got the Sozobon C, the dlibs package and the
> 	gemfast libraries off the net. I am looking for suggestions
> 	as to the way to configure these on my system. I have a 
> 	standard 520 with a 1/2 meg and a single sided drive.
> 	The compiler, dlibs and gemfast will not fit on one disk.
> 	Oh, I also want to use Gulam as my shell. Any suggestions?
> 	
You really need another drive or an SF314.

You may be able to get cc, hcc, top, jas and ld onto a Twister-formatted
SSDD disk along with dLibs, the header files, the startup module and
GEMFAST. You could boot Gulam from a separate disk, then swap to the
compiler. Unfortunately, that doesn't leave any space for the program that
you're writing. Depending on how much RAM is eaten by Gulam, you may be
able to get a small RAMdisk installed and still leave enough for Sozobon
to run -- I think it takes about 230K of free memory. You also may find
that it just can't be done.

I'm running with two single-sided drives. I have the compiler stuff on A:
along with MicroEMACS 2.19 (about 61K) and have to put the GEM libraries
on B: with my .c files. 

> From: hofer@lan.informatik.tu-muenchen.dbp.de.UUCP
> Subject: Sozobon C

> I have some Problems with Sozobon C and hope someone outhere can help
> me. I use the compiler with my Mega ST 2, 1 MB Ramdisk and the gulam   
> shell.
> 
> The first problem: Sometimes i invoke cc from gulam, jas print the 
> message "cant't open object file for writing". After i have exit gulam
> and restart it, jas has no problem anymore. 

That sounds like a Gulam problem, possibly with reading the environment.

> 
> The second problem: After i have invoked cc -v t.c (The -v flag isn't
> nessecary to get this problem) the following text is on my screen:
>   cc -v t.c
>   d:\sozobon\bin\hcc.ttp t.c
>   d:\sozobon\bin\jas.ttp -l -u t.s
>   d:\sozobon\bin\ld.ttp -p -u _main -o t.ttp -f ldfile.tmp
>   Undef _main from \sozobon(main.o)
>   Bad sym type
>   cc: loader failed
>   cmd exit code 1

The main.o module in dlibs does some setup work, then calls _main: (in
assembler), which is main() (in C). My guess is that ldfile.tmp isn't
being written correctly by cc, and isn't including your t.o file. Try
halting the process (cntrl-C) before cc has a chance to delete ldfile.tmp,
and take a look.

One other thing: You almost always should run with the optimizer enabled.
The main compiler (hcc) writes completely ass-backwards assembly language,
requiring the CPU to play leapfrog while executing code. Tony's optimizer
(top) untangles all that. You can just add -O to the cc command line (note
that it should be capitalized), or you can recompile CC to hard-wire
optimization "on" (which is what I did).

The exception to the rule is when you wish to include in-line assembler.
If you do something like
a001()
{
	asm(".dc.w $A001");
}
  the optimizer won't know how to handle it. In that case, run hcc and jas
to compile the module separately.


*   Watch that return address! Reply to:
*   stag!thelake!steve@bungia.mn.org  (UUCP)
*   crash!pnet51!steve@trout.nosc.mil (ARPA)