Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site k.cs.cmu.edu Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!ariel!mtunh!akguc!akgua!gatech!seismo!rochester!pt.cs.cmu.edu!k.cs.cmu.edu!tim From: tim@k.cs.cmu.edu (Tim Maroney) Newsgroups: net.micro.mac Subject: Re: Using the Macintosh Toolbox with C (toolbox glue) Message-ID: <702@k.cs.cmu.edu> Date: Wed, 11-Dec-85 08:18:38 EST Article-I.D.: k.702 Posted: Wed Dec 11 08:18:38 1985 Date-Received: Sat, 14-Dec-85 23:41:34 EST References: <198@gould9.UUCP> Organization: Carnegie-Mellon University, Networking Lines: 57 Thanks to Joel West for his reasoned response. However, I think that there were some flaws in his analysis of the issue of "smart" (compiler-generated) toolbox interfaces versus "glue" (linker-generated) toolbox interfaces. > it > may be that a system with "glue" routines will support a new feature > (e.g. Appletalk) 6 months before one where the compiler has to be > modified. It may also mean that the interfaces are less buggy because > they're easier to implement. (I'm not saying this is necessarily true...) But even in a "smart" compiler, glue routines can still be used, so the first point doesn't apply. Glue routines can be created as a temporary fix in this case, pending later compiler modification. Also, this makes an assumption which is understandable and probably is the case for all existing compilers; but it is not necessary that a smart compiler store object code with which it generates toolbox interfaces. It would be easy enough to keep specifications of the interfaces in an external file, editable using an ASCII text editor. The language of the file would be quite small, and could be parsed and stored in the compiler symbol table at compiler startup. It would take a few seconds, but parsing small languages like this is pretty fast; the file could even be kept in a binary format, with an associated editor program, so not even parsing would be needed, only file I/O. Any compiler implementor worth his pay should be able to put something like this together in less than a week. This would mean that no compiler modifications would be needed, ever. It would also mean that bug fixes could be easily done, and that the interfaces would be MORE reliable, not less, being specified non-procedurally (that is, you don't write code to put out the interface, but just specify the interface's format). By the way, Appletalk was a bad example. The low-level interface is through device driver control calls, requiring no new interfaces. The high-level interface is not in ROM and so is always a "glue routine", though it does a lot more than just providing a nice calling sequence. > I would also note that the Megamax has been near the top or at the > top on every speed benchmark I've seen. And they were the first > with the smart linker, so their programs were faster. Right, but this is not important. Toolbox interface speed is not the only factor in run-time speed and size. Megamax C seems to produce fairly good code for control constructs (loops, conditionals, etc.) and to do a small amount of optimization; it produces good object code. Its speed is DESPITE, not BECAUSE, of its glue routines. There is no way that glue routines which reconstrct stack frames and increase the number of instructions executed with each toolbox call can be faster than smart interfaces generated in line. (Unless, that is, they read the trap addresses at program startup and use those rather than trapping -- this would require modifying SetTrapAddress to also update the glue routine, but it could be done....) I was only discussing the effects of one compiler design decision, not making a general judgment on which compilers are better overall. Sorry if this was unclear (which, judging from my mail, it was.) -=- Tim Maroney, Electronic Village Idiot, CMU Center for Art and Technology tim@k.cs.cmu.edu | uucp: {seismo,decwrl,ucbvax,etc.}!k.cs.cmu.edu!tim CompuServe: 74176,1360 | Offense is an inevitable consequence of honesty.