Xref: utzoo comp.lang.c:12514 comp.arch:6311
Path: utzoo!attcan!uunet!mcvax!hp4nl!mhres!jv
From: jv@mhres.mh.nl (Johan Vromans)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: HP/Rumors
Message-ID: <2336@mhres.mh.nl>
Date: 9 Sep 88 08:23:47 GMT
References: <2921@ttrdc.UUCP>
Organization: Multihouse NV, the Netherlands
Lines: 27

From article <2921@ttrdc.UUCP>, by levy@ttrdc.UUCP (Daniel R. Levy):
> What are the implications of this "relocation of data in memory during
> execution" and why would it cause Emacs problems but not problems in
> general with C programs which use pointers.  (If the HP9000 will move a
> block of memory after a pointer to it has been loaded, then the pointer is
> now no good... or is it?)

As I remember ... an pointer on the HP9000/500 system is
something you cannot treat as an numeric quantity. Of course, you
should not do that anyway.
I recall the following symptoms:
 - address space is not contiguous from zero to somewhere,
   pointers contain segment numbers and offsets;
 - you cannot store a pointer on disk, and read it back in
   another run, because your program will probably not be loaded
   in the same memory segments;
 - you cannot use the highest bits of a pointer for other
   purposes (as GNU Emacs does). All 32 bits contain information.

When you use pointers thru C (e.g. "ptr1 - ptr2" or "ptr[index]")
everything goes well, that's why "normal" applications are not
affected. 

Another feature of the HP9000/500 is that local variables are
garanteed to contain 0 (zero) at startup.
-- 
	Johan