🚀 go-pugleaf

In article <7508@dartvax.UUCP> earleh@dartvax.UUCP (Earle R. Horton) writes:
>Perhaps someone would care to enlighten me as to why the sumacc compiler has
>apparently fallen into disuse.  Is it solely the inconvenience of having to
>download the compiled program (I can live with that) or is there something
>wrong with it?

Well, there are two things wrong with it:

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.

2.) it is buggy.  

You may have seen my shareware program, Calendar 1.9. It is loosely
based on a program that was broadcast to the net in, I think '84, that
was compiled in sumacc C. I liked the program, but it hhad an obvious
killer bug, as a result of the Sumacc compiler.  (The symptoms were,
if you used the Calendar desk accessory once, then you couldn't use it
again until you quit the current application.) After trying,
unsuccessfully to contact the author, I took over development of the
program, and have added many new features and fixed many old bugs.

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.

Conclusion:
Don't use sumacc C. Because of its authors' poor understanding of the
Macintosh execution time environment, the sumacc C compiler generates
incorrect code.

--- David Phillip Oster            --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu