rlk@fortune.UUCP (Robert Krause Rlk) (03/26/88)
I work for Fortune Systems in Berkeley. I'm in the process of porting gnumacs to Fortune's soon-to-be-released 5.3.1 Un*x system that runs in a 68020 box. The problem I'm currently confronted with is that the code having to do with Lisp_Objects seems to assume that these objects are at most 4 bytes in length. With a type field of at least 5 bits, that leaves only 24 to 28 bits for an address field. Given that our stacks grow downward from 0x1fffffff and our data segments grow upward from 0x4a00000 we can't contain the necessary pointer in 28 bits or less. I can think of several possible solutions (read kludges) to this problem but before I begin implementing anything I would like to know if anybody else has had this problem and whether a concensus has developed as to how to resolve it. Reply to me directly if you like but this may be of common interest to the net if it has not already been discussed. Bob Krause hplabs!fortune!forbrk!rlk 2560 9th St. Berkeley, Ca. 94703
ford@kenobi.UUCP (Mike Ditto) (03/29/88)
In article <481@fortune.UUCP> rlk@fortune.UUCP (Robert Krause Rlk) writes: > I work for Fortune Systems in Berkeley. I'm in the process of > porting gnumacs to Fortune's soon-to-be-released 5.3.1 Un*x system > that runs in a 68020 box. The problem I'm currently confronted with > is that the code having to do with Lisp_Objects seems to assume that > these objects are at most 4 bytes in length. With a type field of > at least 5 bits, that leaves only 24 to 28 bits for an address > field. Given that our stacks grow downward from 0x1fffffff and our > data segments grow upward from 0x4a00000 we can't contain the > necessary pointer in 28 bits or less. I can think of several > possible solutions (read kludges) to this problem but before I begin > implementing anything I would like to know if anybody else has had > this problem and whether a concensus has developed as to how to > resolve it. [Normal 680X0 systems have address space starting at zero. Why was this one made so strange? 68020 system designers take note.] I faced the same problem in making Gnu Emacs run under HP-UX on an HP-9000 series 500, on which effectively all 32 bits of addresses are used. I made it work by making Lisp_Object a structure, with an 'address' field and a 'type' field. Since this requires having functions that are passed and return 8-byte structures, Emacs runs a bit slowly. It did allow lisp integers to have full 32-bit values, though. Another problem with this approach is that Emacs uses the XFASTINT macro sometimes as an lvalue, and other times as an rvalue. When it is used as an lvalue, it must set the type of the object to integer. I made that work with a really bizarre macro which will set the type to 'int' in either case. The result is an XFASTINT that is SLOWER than just XINT or XSETINT. This is a design problem in Emacs, which should be fixed by having two different XFASTINT macros. There are some places in the source that mis-use XFASTINT as a way to refer to a Lisp_Object as a whole. Many of these are in lisp.h, such as: #define NULL(x) (XFASTINT (x) == XFASTINT (Qnil)) which would also return true if 'x' were an integer whose value happened to equal the address of Qnil's symbol structure. This sort of thing must be corrected. There are about a half-dozen bugs in Emacs which cause problems when NO_UNION_TYPE is NOT defined (as is the case when Lisp_Object is not an integer). These must be fixed for things to work completely. All of the above comments apply to a rather old version of Gnu Emacs, I beleive it was 17.49 or thereabouts. I no longer work at the company where I did the hp9000s500 port, so I haven't merged it into anything more recent, and I would have to make special arrangements to even get a copy of the version I had running. I never tried to get unexec working on the hp9000s500. On SCO 80386 Xenix, the range of addresses was only 25 bits, so redefining VALBITS as 25 was sufficient. It's interesting to note that even an Intel processor can run emacs more easily than a 68020 if the 68020 system is designed in a strange way. I'm not saying the system discussed above is bad, just that it's strange. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads