🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #11783

Re: CBM, Why did you make it so hard?

#11783
From: Jim Mackraz
Date: Mon, 13 Mar 1989 21:56
97 lines
5291 bytes
In article <913@dover.uucp> fullmer@dover.UUCP (Glen Fullmer) writes:
)1.  Why didn't the developers of the C compilers agree on a common linkable
)    format?

The culprit was Aztec, but at the time their linking speed was so much
quicker that nobody minded.  They also had different register conventions,
which will also haunt you.  Read the register conventions in both 
the RKM (pertains also to Lattice) and the Aztec manuals.

)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?

Write it as an Exec library, in any language, respecting the register
parameter passing interface.  Each language then requires an interface
technique on the calling side, normally a link library.  New lattice
can use some #pragma files instead.  Create a .fd file, and then either
find tools to convert to link code or pragmas, or hand tool them.  The
technique is traditionally assembler stubs.  Examine the source to
Aztec's link libraries.

You will also need to do a library-side interface to get the parameters
out of registers, again compiler specific, but you only do this once,
for the compiler you implement the library with.  This is typically
done in assembler.

The key point is that the interface favors neither compiler: it is
for assembly language programming.  It is common practice for all
languages to translate in and out of that interface.

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

I don't follow.  Unless you are using interrupts as part of the package,
the system will restore you without your ever knowing.  All registers must
be saved/restored by an interrupt, since you could be in the middle of
anything.  If you want to write interrupts in C, you must have an
assembler interface that saves/restores all parameters you might
change.  See the Guru's Guide on Interrupts.

)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?

Most system libraries don't have a notion of "session," that is, there is
typically no preserved state.  To do this, you would just introduce
a "handle" that is returned by InitSession() and passed to every pertinent
call (including EndSession()).  I guess you could say the OpenWindow() is
doing just that.  Think also about the model of a RastPort: it isn't
session-based, but it is a handle.  It has an Init() (although no Create()),
and no End().

)5.  How did CBM do this for their libraries?

Pretty much as I describe, except we have tools to go from .fd to
the lattice/amiga style interface links in amiga.lib.  Our C functions
have assembler stubs pulling parameters out of registers.  Non-conforming
vendors (such as Aztec and the Modula folks) have their own stubs, created
from the .fd's, which their applications link to for library interfaces.

)6.  Why isn't it simpler?

Actually, the stuff you are asking about is pretty "mechanical" once
you gather the pieces.  What is nowhere near as straightforward is
the traditional part of being re-entrant, which must be approached with
EXTREME CAUTION.

You can get bit in the butt by all sorts of things, many of which
show no problem during development time.  Hanging something off a
list that is shared, toggling a bit in a shared flags word, asking
most C compilers to return a structure, changing a string (overwriting
the null terminator), all this stuff can bite your butt.

Implementing a library is a hurdle, but reentrant code is a science.
I've heard some people argue that the technology of writing libraries
is best left a little arcane, so as to keep it out of the hands of
the naive.  I don't subscribe to this point of view, but I sympathize
with the intent.  Writing most shared code is HARD, and the bugs
can be very subtle.

)Granted, a lot of this is probably very naive for some of you guys, but
)where does one learn it?  References?

The best source is examples.  I have one, elib, on the fish disks somewhere.
It is written in Aztec, small model, and includes demonstrations of link
routines for Aztec.  It is not hard to add links for lattice callers.

I am also doing one up using all the new high-powered Lattice 5.0X stuff.

	jimm

-- 
Jim Mackraz, I and I Computing	   	"Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm          from the trees: We're in transition."
							- Gang of Four
Opinions are my own.  Comments are not to be taken as Commodore official policy.
Technical Details
Message-ID: <3623@amiga.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amiga!jimm
References: <913@dover.uucp>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CBM, Why did you make it so hard?
Keywords: Graphics Libraries, reentrancy
Message-ID: <3623@amiga.UUCP>
Date: 13 Mar 89 21:56:28 GMT
References: <913@dover.uucp>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 97