Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!husc6!ut-sally!brian From: brian@ut-sally.UUCP (Brian H. Powell) Newsgroups: comp.sys.mac Subject: Re: What is wrong with the Sumacc C compiler Message-ID: <9431@ut-sally.UUCP> Date: Fri, 30-Oct-87 15:00:29 EST Article-I.D.: ut-sally.9431 Posted: Fri Oct 30 15:00:29 1987 Date-Received: Wed, 4-Nov-87 22:47:46 EST References: <7486@dartvax.UUCP> <7508@dartvax.UUCP> <21522@ucbvax.BERKELEY.EDU> Organization: U. Texas CS Dept., Austin, Texas Lines: 71 Keywords: C compiler gripe In article <21522@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > 1.) it is slow. > Unless you have a Mac with an ethernet connection to a _very_ fast machine, > it is much faster to compile and link locally than to compile on a remote > machine, link, rmake, and down load the result. Agreed. I think a 9600 baud connection would be tolerable, though. > 2.) it is buggy. Agreed. Buggy but usable. I only ran into one code generation bug. The problem you describe is a feature, not a bug. and let me add 3) you can't do segmentation. Segmentation, as we all know, is a means of getting around the problem that the mac has with segments of code that are larger than 32K. This meant that you couldn't write a program in SUMacC that was larger than 32K. As I recall that was a bug in the resource manager (you couldn't have a resource (e.g., CODE) that was larger than 32K.) I don't know if there are still inherent limitations that prevent a CODE resource from being larger than 32K. Comments anyone? (Aside: an advantage of limiting code to 32K chunks is that a compiler can always set aside 16 bits for an offset; it will never have to set aside 32 bits, since everyplace it would ever want to jump (or jsr) to is within 32K of where you are.) (I would bet the SUMacC compiler is probably intelligent enough to use the right size offsets (16 bits normally, 32 when needed.)) I seem to recall, back when I was coordinating the updates to the SUMacC "rmaker" resource compiler, that someone said they had added segmentation to the SUMacC compiler. > The authors of the compiler seem to be unaware that on a Macintosh > executable code can move while the program is running. Unlike all Macintosh > compilers, they generate position _dependent_ code, and have a funky > loader scheme to resolve non-relocatable references at program load > time. Eventually, the code moves, and all that position dependent code > points at never-neverland. SUMacC does indeed do run-time relocation (once, the first time the code is called). If anybody ever wants to know how it works, you can ask me. (That's what the "longruns" are when you rmaker the file.) This works fine for applications written in SUMacC because they are only one segment. The main segment is always locked in memory, so it never moves. This doesn't work for desk ornaments, as described in the parent article. Once closed, they are unlocked. The next time the DA is opened, it's locked again, but it may have moved in the meantime. Boom. I consider SUMacC to be outdated, and I don't think it should be used as a development environment for anything serious, especially something like kermit. SUMacC was great back when it was the only way other than the lisa to develop programs for the mac. It was also great for those of us who only had 128K macs. (Ever try to develop software on a 128K Mac? I have. Remember the old megamax compiler that used the screen memory... Those were the good old days...) For SUMacC to be competitive, it would have to generate position-independent code, and it would have to provide segmentation. It's code generation is among the best (if not the best) considering it does a reasonably good job at optimization. Brian H. Powell UUCP: ...!uunet!ut-sally!brian ARPA: brian@sally.UTEXAS.EDU _Work_ _Not Work_ Department of Computer Sciences P.O. Box 5899 Taylor Hall 2.124 Austin, TX 78763-5899 The University of Texas at Austin (512) 346-0835 Austin, TX 78712-1188 (512) 471-9536