🚀 go-pugleaf

In article <9431@ut-sally.UUCP>, brian@ut-sally.UUCP (Brian H. Powell) writes:

>      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

The bug in the resource manager appears to affect writing resources larger
than 32k, and not reading them from disk.  The CODE resource for Kermit is
about 64k in size when compiled with the Sumacc compiler here.  Apparently,
you can have CODE resources as big as you want, as long as you don't use
the resource manager to write them out.

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

It does a good job of linking, too.  Kermit made with Sumacc is about 71k,
while Kermit made with Megamax is 85k.  It's really tempting to use Sumacc,
since the tools available (make, emacs, csh, real background processing, etc.)
are about 100 times better than what exists on the Mac, and they just got
new disk drives for the VAX, and we can download files here using Darterminal
and Appletalk...

The large volume of information I received in reply to my original query
indicates that Sumacc probably is not a real good choice for doing Mac
development, but that it sure would be nice if it were.  I guess I will stick
with Lightspeed.  It may not optimize, but at least it compiles ROM calls
inline (well, most of them, anyway.)
-- 
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755   *
*********************************************************************