Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!lll-lcc!pyramid!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CBM, Why did you make it so hard?
Keywords: Graphics Libraries, reentrancy
Message-ID: <6279@cbmvax.UUCP>
Date: 15 Mar 89 04:15:19 GMT
References: <913@dover.uucp>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 58

In article <913@dover.uucp> fullmer@dover.UUCP (Glen Fullmer) writes:
>that anyone can call at run time.  That was fine.  After a number of weeks
>trying to track down all that has been written about Amiga-shared libraries
>(which is precious little) and "ripping off" as much public-domain code that 
>he could find, has written a single-user-at-a-time graphics library.  I,

	There is an example library in the RKMs, and I think available in 
source code form somewhere.  There are libraries (source) on fish disks too.

>being as helpful as usual, suggested that a single-user-at-a-time graphics
>library is not very useful, especially if one wants to write a generic
>widowing system with his library (which I do).  I suggested that he rewrite
>his graphics library so that it is re-executable and reentrant (being the
>helpful person that I am).  Given that history, we have a number of questions:

	Most libraries should be reentrant.

>1.  Why didn't the developers of the C compilers agree on a common linkable
>    format?

	Ask them.  Lattice supports the Amiga Object File Format, Manx (I think)
preferred to use the same format they had used on other machines.  I think most
of the Modula writers use amiga object files, but I'm not sure.

>2.  How does one make a generic package, like his graphics package, both
>    reexecutable and reentrant?  Does it require specific register allocation
>    via assembler programming?  Or is there an easier way? A different 
>    global hook that can be used to hang environments on?

	The only real trick is to set up the global data pointer correctly,
and to use locking of shared global structures.  Most libraries have global
data in the librarybase, which you always get a pointer to at entry (in a6).
You don't have to though.  If you do a geta4() (check manx docs) at each
entrypoint, then you can access your globals.  Be careful with library routines
that may use globals (stdio is right out).  Use Semaphores for locking access
to structures in the base when needed (sometimes Forbid()/Permit() is 
reasonable, but please don't use it unless needed).

>3.  How does one restore the environment, for example, after an interrupt?

	Are you writing interrupt handlers??  I think they're well documented;
I highly advise NOT writing interrupt handlers in anything but ASM.

>4.  Is making a package that must retain context both over the life of a 
>    call and the life of the session different than  "pure" residentable
>    code?  If so, how are they different, and what are the coding 
>    differences?

	Your question isn't clear.  If by "context" you mean data, then yes,
many calls returns pointers (cookies) you have to pass back when doing other
calls (FileHandles, for example).  "Pure" code merely means there are no
hard references to globals, and thus can be invoked multiple times safely.
Most programs do this by either not having any globals or never modifying
any globals.  Some (ex: lattice with cres.o) do it by allocating the data
segments, and accessing them via a base pointer.

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