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.