Path: utzoo!attcan!uunet!husc6!bbn!apple!versatc!mips!prls!philabs!linus!raybed2!cvbnet2!perry!jnuss
From: jnuss@perry.prime.com (Jeremy Nussbaum)
Newsgroups: comp.windows.news
Subject: Re: NeWS For VaxStations (Micro Vaxes, etc)
Summary: Pointer tricks
Message-ID: <1158@cvbnet2.UUCP>
Date: 19 May 89 13:55:42 GMT
References: <8905132111.AA19260@fnord.umiacs.UMD.EDU> <23810@pprg.unm.edu> <33046@sgi.SGI.COM>
Sender: root@cvbnet2.UUCP
Reply-To: jeremy@jeremy.prime.com (Jeremy Nussbaum)
Organization: Prime Computervision, Bedford MA
Lines: 16

In article <33046@sgi.SGI.COM> msc@ramoth.SGI.COM (Mark Callow) writes:
>The problem is that NeWS assumes that 26 bits is enough for the pointer
>(offset) from the object to the object body.  Since the MIPS loader
>chooses to place the data segment at 0x10000000, you need 28 bits.
>There is a flag to our (SGI's) MIPS loader, -D, that lets you put the
>data segment somewhere else. ... ugly choices:  increase the object 
>structure size or OR in the unchanging high bits of the address.
>  I chose the latter.

Gnu emacs had the same  problem with the mlisp 
interpreter  on the IBM RT, as well as on the SGI 
mips based WS. The solution they chose was also to 
OR in the start of the data segment into  the 
pointer.  In e.g. 18.51, see the lisp.h file where 
the pointer  extraction is or'ed with DATA_SEG_BITS 
if necessary.