Path: 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 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.