[comp.sys.amiga.tech] Lattice startup code questions

rlcarr@athena.mit.edu (Rich Carreiro) (02/19/89)

I have some questions about C startup code - what exactly does it have
to do?  I waslooking through the KICKSTART GUIDE TO THE AMIGA and saw the
following:

/* OurStart.c - simple startup code */
#include <exec/types.h>
#define KNOWN_ADDRESS 4

extern APTR OpenLibrary();
extern VOID CloseLibrary();

APTR SysBase;
APTR DOSBase;

OurStart()
{
   SysBase = *((APTR *) KNOWN_ADDRESS);
   DOSBase = OpenLibrary("dos.library",0);

   main();
   CloseLibrary(DOSBase);
}

and to be used with it:

/* beep.c - link with ourstart.o */
#include <exec/types.h>

extern APTR OpenLibrary();
extern VOID CloseLibrary(), DisplayBeep();

APTR IntuitionBase;

main()
{
   int i;

   IntuitionBase = OpenLibrary("intuition.library",29);

   if (IntuitionBase != 0) {

      for (i=0;i<6;i++) {
	DisplayBeep();
        Delay(5);
      }
   CloseLibrary(IntuitionBase);
   }
}

I compile each with 'lc -v filename' and they compile fine.  I next do
'blink from ourstart.o+beep.o to beep lib lib:amiga.lib' [I have
Latice 5.02]  and it links fine.  When I run it, instant Guru 4.  When
I recompile with debug information and do a 
'blink from ourstart.o+beep.o to beep lib lib:amiga.lib addsym' and
to a 'cpr beep' cpr comes up, displays the source starting at OurStart(), 
not main(), and then locks up.  I can move slider bars and MachII keeps working
but cpr won't respond to anything.  Note that beep.c works fine if I link
it with c.o, lc.lib, and amiga.lib.  Also, when I link with ourstart.o, cpr
reports that beep has 2 modules, while if I link with c.o et al., cpr says
there is only one module.  I have looked through c.a to get an idea of what
it is doing, but I don't know assembly.

Finally, all the books on C pertaining to the Amiga talk about linking
with the AStartup.obj and LStartup.obj startup codes.  I have gathered
that LStartup.obj is now c.o and is used when you want Lattice library
(lc.lib) I/O.  Astartup.obj was used when you didn't care about UNIX
commend line emulation and wanted Amiga, not lattice I/O - in this
even you also linked amiga.lib AHEAD of lc.lib.  My question is - with
Lattice 5.02, what is the equivalent of Astartup.obj?

Any answers, comments, corrections to any of this will be more than
appreciated.

ARPA:    rlcarr@athena.mit.edu
UUCP:    {wherever}!mit-eddie!mit-athena!rlcarr
BITNET:  rlcarr%athena.mit.edu@MITVMA.mit.edu

*******************************************************************************
* Rich Carreiro                 "Back off man, I'm a scientist."              *
* rlcarr@athena.mit.edu                - Dr. Peter Venkman                    *
*******************************************************************************

cmcmanis%pepper@Sun.COM (Chuck McManis) (02/20/89)

In article <9322@bloom-beacon.MIT.EDU> (Rich Carreiro) writes:

>I have some questions about C startup code - what exactly does it have
>to do? 

All it _has_ to do is set up the "environment" for the "main" program.
C programs want stdin/stdout/stderr setup, and to have arguments parsed
into the argv array. Assembly programs don't care. The startup code is
also responsible for opening whatever minimum set of libraries you will
need, and since it will regain control after your program exits, for 
closing those libraries as well. In Lattice's case they also take care
of handling the workbench startup message you get sent when the user
double-clicks on an icon that activates your program. 

[Code example deleted]

>I compile each with 'lc -v filename' and they compile fine.  I next do
>'blink from ourstart.o+beep.o to beep lib lib:amiga.lib' [I have
>Latice 5.02]  and it links fine.  When I run it, instant Guru 4.  

My guess is that your code never manages to open Intuition, falls out
the bottom of main with an undefined value, and falls out of your startup
code into uninitialized memory. At some point you have to call Exit() to
get back to your original CLI. 

>Finally, all the books on C pertaining to the Amiga talk about linking
>with the AStartup.obj and LStartup.obj startup codes.  I have gathered
>that LStartup.obj is now c.o and is used when you want Lattice library
>(lc.lib) I/O.  Astartup.obj was used when you didn't care about UNIX
>commend line emulation and wanted Amiga, not lattice I/O - in this
>even you also linked amiga.lib AHEAD of lc.lib.  My question is - with
>Lattice 5.02, what is the equivalent of Astartup.obj?

Well, Carolyn Scheppner put a bunch of startup modules on BIX and on
a Fish disk I believe. These were TWStartup et al. They are the what 
{A|L}Startup.obj became. Generally, with the 5.0 libcall stuff and
and judicious programming you can link with _no_ libraries and get
a really tight executable. 

>Any answers, comments, corrections to any of this will be more than
>appreciated.

Not real helpful but a couple of pointers to work on ...


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

jesup@cbmvax.UUCP (Randell Jesup) (02/23/89)

In article <90452@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <9322@bloom-beacon.MIT.EDU> (Rich Carreiro) writes:
>
>>I have some questions about C startup code - what exactly does it have
>>to do? 

>closing those libraries as well. In Lattice's case they also take care
>of handling the workbench startup message you get sent when the user
>double-clicks on an icon that activates your program. 

	It also sets up A4 to point to the merged data area, unless you
compile everything with -b0.  This is very important - look in the lattice
c.a file for more info.  _main.c will have the rest of the startup stuff
(where it actually calls main()).

>My guess is that your code never manages to open Intuition, falls out
>the bottom of main with an undefined value, and falls out of your startup
>code into uninitialized memory. At some point you have to call Exit() to
>get back to your original CLI. 

	Please, use exit() or equivalent (XCEXIT in lattice c.a) instead
of Exit().  Exit is really more for BCPL, and with most compilers you
should call a cleanup routine.  Look at c.a, once again.

>Well, Carolyn Scheppner put a bunch of startup modules on BIX and on
>a Fish disk I believe. These were TWStartup et al. They are the what 
>{A|L}Startup.obj became. Generally, with the 5.0 libcall stuff and
>and judicious programming you can link with _no_ libraries and get
>a really tight executable. 

	Once again, be careful of the A4 stuff, or compile everything with
-b0.  Or you can modify twstartup to do c.a stuff, or modify c.a to do
twstartup stuff.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup

cmcmanis%pepper@Sun.COM (Chuck McManis) (02/24/89)

In article <6054@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>	Please, use exit() or equivalent (XCEXIT in lattice c.a) instead
>of Exit().  Exit is really more for BCPL, and with most compilers you
>should call a cleanup routine.  Look at c.a, once again.

Randell missed the point, maybe you did too. *Don't* use the compiler 
exit() if you *didn't* use the compiler startup file. The exit routine
will often make assumptions about what the startup module did. And 
since we were explicitly _not_ going to use the c.a startup module 
you can't use exit(). You must use another method, I've found that
Exit() works, but in the c.a module Lattice simply wacks the stack
and does an rts. Guess you might have to experiment to get it right.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

erd@tut.cis.ohio-state.edu (Ethan R. Dicks) (02/25/89)

In article <90987@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <6054@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>	Please, use exit() or equivalent (XCEXIT in lattice c.a) instead
>>of Exit().  Exit is really more for BCPL, and with most compilers you
>>should call a cleanup routine.  Look at c.a, once again.
>
>Randell missed the point, maybe you did too. *Don't* use the compiler 
>exit() if you *didn't* use the compiler startup file.


OK... so to those who know... what should we do?  I have been writing
code for Lattice (currently 5.0, soon to be 5.02) without linking in the
startup module.  I looked back at my code and noticed that I never call
any exit() type of function; I just close all my braces and let main()
end.  Should I be calling an exit()?  Is there a list of hints and tips
for those people, like myself, who write C without linking in startup code?


Thanks,
-ethan

-- 
Ethan R. Dicks       | ######  This signifies that the poster is a member in
Software Results Corp|   ##    good sitting of Inertia House: Bodies at rest.
940 Freeway Drive N. |   ##
Columbus OH    43229 | ######  "You get it, you're closer.

mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (03/03/89)

In article <9322@bloom-beacon.MIT.EDU> rlcarr@athena.mit.edu (Rich Carreiro) writes:
<
<I have some questions about C startup code - what exactly does it have
<to do?  I waslooking through the KICKSTART GUIDE TO THE AMIGA and saw the
<following:
<
</* OurStart.c - simple startup code */

[Code deleted]

<I compile each with 'lc -v filename' and they compile fine.  I next do
<'blink from ourstart.o+beep.o to beep lib lib:amiga.lib' [I have
<Latice 5.02]  and it links fine.  When I run it, instant Guru 4.  When
<I recompile with debug information and do a 
<'blink from ourstart.o+beep.o to beep lib lib:amiga.lib addsym' and
<to a 'cpr beep' cpr comes up, displays the source starting at OurStart(), 
<not main(), and then locks up.  I can move slider bars and MachII keeps working
<but cpr won't respond to anything.  Note that beep.c works fine if I link
<it with c.o, lc.lib, and amiga.lib.  Also, when I link with ourstart.o, cpr
<reports that beep has 2 modules, while if I link with c.o et al., cpr says
<there is only one module.  I have looked through c.a to get an idea of what
<it is doing, but I don't know assembly.

I can see two potential problems - except I don't have manuals, so I'm
sure to make a mistake, which someone will then correct. Oh well, no
one else has poined these out, so...

1) I don't see a starting point specified for OurStart(). Maybe BLINK
defaults to someting intelligent, but I'd be leery of it.

2) In starting cpr, you should specify that it not run the startup code
(-s switch, I believe). I wouldn't be surprised if it's getting
confused and hanging.

	<mike
--
So this is where the future lies			Mike Meyer
In a beer gut belly; In an open fly			mwm@berkeley.edu
Brilcreamed, acrylic, mindless boys			ucbvax!mwm
Punching, kicking, making noise				mwm@ucbjade.BITNET