Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!teddy!panda!talcott!harvard!seismo!utah-cs!jwp
From: jwp@utah-cs.UUCP (John W Peterson)
Newsgroups: net.micro.mac
Subject: Re: high byte of address question
Message-ID: <3184@utah-cs.UUCP>
Date: Fri, 18-Jan-85 02:03:23 EST
Article-I.D.: utah-cs.3184
Posted: Fri Jan 18 02:03:23 1985
Date-Received: Mon, 21-Jan-85 02:34:55 EST
References: <224@ucbopal.CC.Berkeley.ARPA>
Organization: Univ of Utah CS Dept
Lines: 13

The reason the high byte gets trashed in SumacC code has nothing to do
with the Mac hardware, but instead is a side-effect of the Sumacc
relocation scheme.  Unlike the Lisa/Workshop Pascal compiler, Sumacc
does not generate position independant code.  Since C compiler and
loader have no way of knowing where the code will be loaded (this is
decided dynamicly by the Mac memory manager), addresses are resolved
every time a Sumacc program starts up.  

To resolve addresses at startup time, Sumacc uses a "clever" scheme of
run-length encoding relocation info into the high order byte of addresses
that need relocating.  The gory details of how this works can be found
by looking in crtmac.s in the Sumacc lib/ subdirectory.