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-----|
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
bert@hpuamsa.UUCP (Bert_Van Barneveld) (09/12/88)
>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?) The HP9000-500 does (or "did" cause it is obsolete now) not move memory visible to the user (read: his process). The S500 architecture uses different memory areas for different uses. Or it uses hardware segments where UNIX uses software segments if you like it that way. Data segments are not executable in the same way text segments are. It can be done (we had to do it for a Dutch university who wanted to port their LISP compiler to the S500), but it is rather slow and tricky to do ! My feeling is that nobody with in depth knowledge of the S500 ever tried to port emacs. Anyhow, it would not have been trivial. Bert van Barneveld HP Support, The Netherlands.
rminnich@super.ORG (Ronald G Minnich) (09/15/88)
Re: the way emacs uses the top 8 bits of a 32-bit address: It is kinda funny how the wheel turns and turns. There was this machine called the 360, see, with 32 bit addresses but really only 24 of them were used. So people avidly packed those upper 8 bits of state which were never gonna get used anyway, ... until IBM went and used 'em. I never had to fix any of this stuff, but people told me at the time (ca. 1978 or so) that they had heard those bits might go away in a few years and boy, they weren't looking forward to it ... So just a few years later somebody was telling me how wonderful this elegant GNU emacs was, and it used these upper 8 bits of the 32-bit address for a tag mechanism, because they were there for the taking, and wasn't that neat, ... :-) Its not hard to believe that GNU Emacs would be a nightmare on the 500. ron
aglew@urbsdc.Urbana.Gould.COM (09/17/88)
..> GNU Emacs and tags in the upper bits. GNU Emacs *has* been ported to machines that use a full 32 bits of address, like Gould's NP1 and 2 (our PN line only has 24 bit addresses).
joh@oakhill.UUCP (Joe Hollinger) (09/19/88)
In article <28200201@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: > >..> GNU Emacs and tags in the upper bits. > >GNU Emacs *has* been ported to machines that use a full 32 >bits of address, like Gould's NP1 and 2 (our PN line only >has 24 bit addresses). Emacs does run on NP1 but the tags problem is still there. You can reproduce it by using Emacs on a large file, preferably something over 12 megabytes. At some point the tags cause the editor to have multiple lines all with the same virtual address. This alias problem causes the editor to pretty much loose it's mind.
aglew@urbsdc.Urbana.Gould.COM (09/21/88)
>/* Written 9:29 am Sep 19, 1988 by joh@oakhill.UUCP in urbsdc:comp.arch */ >In article <28200201@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: >> >>..> GNU Emacs and tags in the upper bits. >> >>GNU Emacs *has* been ported to machines that use a full 32 >>bits of address, like Gould's NP1 and 2 (our PN line only >>has 24 bit addresses). > >Emacs does run on NP1 but the tags problem is still there. You can >reproduce it by using Emacs on a large file, preferably something over >12 megabytes. At some point the tags cause the editor to have multiple >lines all with the same virtual address. This alias problem causes the >editor to pretty much loose it's mind. >/* End of text from urbsdc:comp.arch */ Well, I *am* embarassed. I'm afraid that's something that'll have to be fixed. <Multiple grumblings>