oster@ucblapis.berkeley.edu (David Phillip Oster) (05/27/86)
LightSpeed C produces buggy desk accessories, and the example desk accesory is dangerous! Lightspeed C is one of those Cs that inserts glue routines to access global variables of desk accessories. The global variables are actually kept in a movable block of storage referenced in a handle that lives in the DCE block of the desk accessory. Bugs: 1) The compiler inserts code to dereference a handle and put a pointer to the storage in regester A4, then reference global variables off of A4. This preamble LOCKS the handle, and never unlocks, so your globals live in a fixed block that contributes to heap fragmentation. 2) Since the preamble code locks the storage before your code ever gets called, you can't even save the lock state of the handle and restore it yourself - the state is already changed before your code ever gets called. 3) Since the storage is handled for you incorrectly, you can't manage it yourself - the only slot for a handle to local storage in a desk accessory is already taken up by the access made from this incorrect code. 4) The sample desk accessory given with the compiler is so wrong that it scribbles on the memory of the application program and can cause random crashes. Do NOT Use it. The problem is that the sample overrides a system trap. When the trap gets called, routines in the desk accessory try to access the global variables of the desk accessory. But since the call is NOT a desk accessory call, it is a tool trap call, register A4 gets a garbage value. (If you run it under MacBug in MacDraw, you can see that register A4 has a 0 in it, when it should have the address of the global block.) 5) The whole library gets included with every program, so a desk accessory that should be about 900 bytes long takes up 4k. It still is a real nicve system, I have written the manufacturer with the above information, I'll let you know what the reply is. Since the compiler generates machine code directly, there is no easy way to look at this code. --- David Phillip Oster -- "The goal of Computer Science is to Arpa: oster@lapis.berkeley.edu -- build something that will last at Uucp: ucbvax!ucblapis!oster -- least until we've finished building it."
dubois@uwmacc.UUCP (Paul DuBois) (05/28/86)
> LightSpeed C produces buggy desk accessories, and the example desk > accesory is dangerous! Lightspeed C is one of those Cs that inserts glue > routines to access global variables of desk accessories... > ...5) The whole library gets included with every program, so a desk > accessory that should be about 900 bytes long takes up 4k. ??? What library is that? I converted my ZoomIdle DA from Rascal to Lightspeed as an exercise. Lightspeed generates 890 bytes of code from my source, which is virtually the same as the amount of code generated by Rascal. The finished Lightspeed DA takes up 2600 bytes - not as good as Rascal (1800 bytes) - but not 4K, either. -- Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois | ARPA: dubois@easter --+-- | Doth the hawk fly by thy wisdom, and stretch her wings | toward the south? Job 39:26
oster@ucblapis.berkeley.edu (David Phillip Oster) (05/29/86)
Re: 5) Whoops, my appology. The window desk accessory included in the LightSpeed C distributiuon has 1800 bytes or so of object code, but generates a 4k desk accessory when linked by LSC to its default libraries. Supplying my own library reduced the size to 3.5k. Now 500 or so extra bytes isn't too bad, but that means the program is about 15% bigger than it should be. The next step is to translate the accessory into T.M.L. pascal and see how the code generation size compares.
paul@fcstools.UUCP (Paul Perkins) (06/01/86)
> LightSpeed C produces buggy desk accessories, and the example desk > accesory is dangerous! > ... > 2) Since the preamble code locks the storage before your code ever gets > called, you can't even save the lock state of the handle and restore it > yourself - the state is already changed before your code ever gets called. The problem is all in your mind, as they say... If you always come into the DA only by the front door (so the autmatic locking is done), you can always unlock the storage when you leave. In DA's where saving and restoring the lock state would have been "necessary and sufficient", it's not hard to keep a variable IN THE DA's STORAGE set to what the previous lock state must have been (assuming it was unlocked when first read in by the resource mangler). This is explained in Lightspeed's own documentation. When you come into the DA, you look at the var, to see if storage was locked, then you make storage locked (if it didn't happen automagically), and set the var to TRUE so any pseudo-reentrant calls will see that it is already, then on the way out you unlock or not, based on the original value of the var, which you kept on the stack of course, and if you unlock you set the var to FALSE. Or something like that. -- Paul Perkins #include <std_disclaimer> Quote: "Some say that Heaven is Hell; some say that Hell is Heaven." -- Kate Bush