Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!udel!burdvax!sdcrdcf!ism780c!ico!cadnetix.UUCP!pem
From: pem@cadnetix.UUCP.UUCP
Newsgroups: comp.sys.mac
Subject: Re: What is wrong with the Sumacc C compiler
Message-ID: <1102@cadnetix.UUCP>
Date: Thu, 12-Nov-87 14:53:57 EST
Article-I.D.: cadnetix.1102
Posted: Thu Nov 12 14:53:57 1987
Date-Received: Sat, 14-Nov-87 16:52:30 EST
References: <7486@dartvax.UUCP> <7508@dartvax.UUCP> <21522@ucbvax.BERKELEY.EDU> <2283@watcgl.waterloo.edu>
Reply-To: pem@cadnetix.UUCP (Paul Meyer)
Organization: Cadnetix Corp., Boulder, CO
Lines: 45
Keywords: C compiler gripe

In article <2283@watcgl.waterloo.edu> kdmoen@watcgl.waterloo.edu (Doug Moen) writes:
>oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>...concerning why the sumacc compiler is no good...
>>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.
>
>Sorry, but this sounds blatantly impossible.  If the code were to move
>while the program is running, then *all of the return addresses and
>function pointers on the stack would become invalid* and the program
>would crash, regardless of what compiler was used to create the program.
>
>Now, I can see that maybe desk accessories might move around,
>*but not application programs*.

Doug, I'm afraid you clearly do not understand the execution-time
environment on the Macintosh.  As David is correct in stating, code
*does* move around at execution time--not code that is executing, but
code in the same program.  The Mac has a smart segment loader which
cooperates with the memory manager in a well-built (read well-written-
by-the-compiler) application.  While code in a segment is executing it
is in a LOCKED relocatable memory block; when no code in a segment is
executing or on the return stack, the block should be unlocked to
allow the memory manager to do what it needs to do most efficiently.
For maximum memory efficiency, explicit Segment Loader calls should be
put in an application's main event loop, as is done automatically by
Lightspeed C and can be done explicitly in Megamax C.

On a 68000-series machine, sufficient fancy addressing modes are
available to make absolute references to data unneccessary except for
using low-memory globals (which of course don't move anyway).  This
kind of coding is what makes code not "dynamically relocatable", and
all programs for the Mac are required to be dynamically relocatable.

Presumably, the sumacc application could be set up as a single
segment, but a single segment can't be more than 32K long.  I have no
hard data on what sumacc does, but if it doesn't cooperate with the
Mac operating system, it will obviously be vulnerable to breaking at
the change of the wind.

-- 
pem@cadnetix.UUCP  (nbires!isis!ico!cadnetix!pem)