[comp.lang.c] HP/Rumors

dc@gcm (Dave Caswell) (09/05/88)

In article <2305@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes:

.I have used an Hewlett-Packard HP9000 model 500, which has a very
.strange memory architecture (uses non-contiguous memory
.segments), and a real stack (which means that uninitialized local variables
.contain a zero). Emacs cannot run on it.
                  ^^^^^^^^^^^^^^^^^^^^^^^
Nonsense, many people use Emacs on HP9000/500.

-- 
Dave Caswell
Greenwich Capital Markets                             uunet!philabs!gcm!dc

jv@mhres.mh.nl (Johan Vromans) (09/06/88)

From article <580@white.gcm>, by dc@gcm (Dave Caswell):
> In article <2305@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes:
> .I have used an Hewlett-Packard HP9000 model 500, which has a very
> .strange memory architecture (uses non-contiguous memory
> .segments), and a real stack (which means that uninitialized local variables
> .contain a zero). Emacs cannot run on it.
>                   ^^^^^^^^^^^^^^^^^^^^^^^
> Nonsense, many people use Emacs on HP9000/500.

A quote from the file etc/MACHINES of the GNU 18.50 distribution:

  "The [HP9000] series 500 has a seriously incompatible memory architecture
  "which relocates data in memory during execution of a program,
  "and support for it would be difficult to implement.

Of course, "other" emacses are available for HP9000 model 500
(MicroEmacs, Jove, Scame, Unipress??).


-- 
	Johan

scf@statware.UUCP (Steve Fullerton) (09/06/88)

In article <580@white.gcm> dc@white.UUCP (Dave Caswell) writes:
>In article <2305@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes:
>
>.I have used an Hewlett-Packard HP9000 model 500, which has a very
>...
>.contain a zero). Emacs cannot run on it.
>                  ^^^^^^^^^^^^^^^^^^^^^^^
>Nonsense, many people use Emacs on HP9000/500.
>

I believe he is probably referring to GNU Emacs which definitely does
not run on the HP9000/500.  There are even references to this fact in
the installation/porting documentation.

About a 15 months ago I ordered Emacs from Unipress software as they said
an HP9000/500 version was available.  `Available' meant that they sent out
a source tape with some comments for the HP9000/500.  I spent several days
to get to a running version but it was so buggy that everything was boxed
up and returned within the week.  Maybe they have it working now...

-- 
Steve Fullerton                        Statware, Inc.
scf%statware.uucp@cs.orst.edu          260 SW Madison Ave, Suite 109
orstcs!statware!scf                    Corvallis, OR  97333
                                       503/753-5382

levy@ttrdc.UUCP (Daniel R. Levy) (09/08/88)

In article <2327@mhres.mh.nl>, jv@mhres.mh.nl (Johan Vromans) writes:
> A quote from the file etc/MACHINES of the GNU 18.50 distribution:
> 
>   "The [HP9000] series 500 has a seriously incompatible memory architecture
>   "which relocates data in memory during execution of a program,
>   "and support for it would be difficult to implement.

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?)
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| Bell Labs Area 61 (R.I.P., TTY)|  AND ARE NOT TO BE IMPUTED TO AT&T.
|        Skokie, Illinois        | 
|-----Path:  att!ttbcad!levy-----|

dc@gcm (Dave Caswell) (09/09/88)

In article <1029@statware.UUCP> scf%statware.UUCP@cs.orst.edu (Steve Fullerton) writes:
.About a 15 months ago I ordered Emacs from Unipress software as they said
.an HP9000/500 version was available.  `Available' meant that they sent out
.a source tape with some comments for the HP9000/500.  I spent several days
.to get to a running version but it was so buggy that everything was boxed
.up and returned within the week.  Maybe they have it working now...

The version of Gosling Emacs we have is datad 1985.
-- 
Dave Caswell
Greenwich Capital Markets                             uunet!philabs!gcm!dc

hans@nlgvax.UUCP (Hans Zuidam) (09/09/88)

In article <2921@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>In article <2327@mhres.mh.nl>, jv@mhres.mh.nl (Johan Vromans) writes:
>> A quote from the file etc/MACHINES of the GNU 18.50 distribution:
>> 
>>   "The [HP9000] series 500 has a seriously incompatible memory architecture
>>   "which relocates data in memory during execution of a program,
>>   "and support for it would be difficult to implement.

(This is from memory)
When I worked at the Eindhoven University of Technology we had 4 HP9000/500s
and we ported emacs to it.

The real problem (with emacs 16.??) we had was that emacs assumed that a machine
with 32 bit words uses only 24 address bits. The upper 8 were assumed to be free
and available for type tags. In essence, it assumed that all machines have a VAX
like addressing scheme. The HP9000/500 uses all 32 bits. This same problem
occurred every time we tried to port a program which made any assumption on the
format of a pointer.

The "problem" is that the HP9000/500 has a segmented memory architecture. Each
pointer consists of a segment number and a segment offset and then some. At load
time the segments are assigned to the program and each pointer (identified as
such in the load file) is fixed up with the segment number of its associated data.
When you have emacs dump itself to create a faster loadable binary, you would
have to write every pointer back with no segment assigned. For arbitrary pointers
this is a hell of a job.

A colleague of mine succeeded in porting it but without the dump facility. If
you are interrested, you can contact him at the following address:

		Geert Leon Janssen
		Eindhoven University of Technology,
		Department of Electrical Engineering,
		P.O. Box 513,
		5600 MB Eindhoven, The Netherlands.
		(UUCP: ...!mcvax!euteal!geert)
-- 
Hans Zuidam                                    E-Mail: hans@nlgvax.UUCP
Philips Telecommunications and Data Systems,   Tel: +31 40 892288
Project Centre Geldrop, Building XR
Willem Alexanderlaan 7B, 5664 AN Geldrop       The Netherlands

jv@mhres.mh.nl (Johan Vromans) (09/09/88)

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

jim.nutt@p11.f15.n114.z1.fidonet.org (jim nutt) (09/13/88)

 > From: jv@mhres.mh.nl (Johan Vromans)
 > Message-ID: <2336@mhres.mh.nl>
 > 
 > 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.

actually sounds a lot like working on an intel iapx86 microprocessor, doesn't it?  the restrictions are much the same.

jim nutt
'the computer handyman'


--  
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...ncar!noao!asuvax!stjhmc!15.11!jim.nutt