Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!dwb
From: dwb@apple.UUCP (David W. Berry)
Newsgroups: comp.sys.mac
Subject: Re: What is wrong with the Sumacc C compiler
Message-ID: <6688@apple.UUCP>
Date: Mon, 9-Nov-87 18:04:11 EST
Article-I.D.: apple.6688
Posted: Mon Nov  9 18:04:11 1987
Date-Received: Wed, 11-Nov-87 21:30:29 EST
References: <7486@dartvax.UUCP> <7508@dartvax.UUCP> <21522@ucbvax.BERKELEY.EDU> <2283@watcgl.waterloo.edu>
Reply-To: dwb@apple.UUCP (David W. Berry)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 36
Keywords: C compiler gripe

In article <2283@watcgl.waterloo.edu> kdmoen@watcgl.waterloo.edu (Doug Moen) writes:
>
>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.
	This (code moving while program runs) is exactly what happens.
There are two types of subroutine calls that get compiled into an application,
some of them are direct pc relative calls to other routines in the same
segment.  The rest are made via the "segment table" which is relative
to a5.  The segment table contains either a branch to the appropriate
address in memory if the segment is loaded or a trap (LoadSeg) that
will load the appropriate segment into memory and lock it in place
if it isn't.

	The return addresses on the stack are kept valid by the programmer
only unloading a segment (which actually changes the segment table
and marks the segment purgeable and moveable, but leaves it in core)
if he can verify that there are no calls to it outstanding on the
stack.  The function pointers on the stack are handled the same way.

	Function pointers in tables, etc. are handled by having them
jump into the segment table (which >never< moves once a program
begins executing) rather than jumping to the subroutine required.

	All in all, it's a rather useful way to implement poor
man's demand paging.  This is, by the way, what allows programs
such as Excel, which has more than 200K of code to execute in a
192K MultiFinder segment.  Much of that 200K of code is rarely
needed, and therefore, rarely if ever loaded, meaning the memory
can be used for other things.
-- 
	David W. Berry
	dwb@well.uucp                   dwb@Delphi
	dwb@apple.com                   973-5168@408.MaBell
Disclaimer: Apple doesn't even know I have an opinion and certainly
	wouldn't want if they did.