🚀 go-pugleaf

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