amit@umn-cs.UUCP (Neta Amit) (05/15/87)
Has GnuEmacs (and GCC ?...) been ported to a Data Genaral MV10000 running DG/UX? Data General is selling CCA Emacs for over $2000, with update fee of over $300 (annually). I'm not at all familiar with our DG machine, and would like to hear from people who are -- on the face of it, are there any reasons why the port should be difficult?
meissner@dg_rtp.UUCP (Michael Meissner) (05/17/87)
In article <1574@umn-cs.UUCP> amit@umn-cs.UUCP (Neta Amit) writes: > Has GnuEmacs (and GCC ?...) been ported to a Data Genaral MV10000 > running DG/UX? Data General is selling CCA Emacs for over $2000, > with update fee of over $300 (annually). > > I'm not at all familiar with our DG machine, and would like to hear > from people who are -- on the face of it, are there any reasons why > the port should be difficult? Disclaimer: I am the project leader of the Data General C compiler, but any opinions are my own, not necessarily DG's. I have been porting GNU emacs as a backround task, to see what kinds of things are needed to enhance our portability. Currently I have 18.41 painting the initial screen, and bombing with '] found in vector' upon reading the loadup.el script. With my current work schedule, I cannot devote more than passing interest in it (so don't expect it soon from me -- I could mail my changes to anybody who wants to continue). The things that I found are: 1) Byte/Word pointer mismatches. The DG machine has two different types of pointers: byte pointers (char *) and word pointers (anything else). If you use one where the other is expected, you lose and a SIGSEGV signal is raised (and you can't return from the signal handler either). Calls to bcopy/bzero seem to be the main culpripts so far. We have an option (-Ccommonformat) that passes all pointers as byte pointers, as well as functions returning pointers, and conversions to/from integers. This has helped to get me to the current stage as quickly as I have. It also uncovered some short- comings which will be fixed in the next release of C and the OS (I can give interested people the workarounds). If GNU had been linted, it would not have these problems. 2) SEGMENT bits. GNU assumes that the top 8 bits of a pointer are 0, but in the DG case they are set to a segment (always 7 for user code at the present). Fortunately, the IBM/PC-RT also had this problem, so there defines that can be set in version 18. 3) Configuration problems also played a part -- DG/UX is a system V.2 system with Berkley directories, Job Control, I/O, and networking added, so selecting which options are needed is hard (in particular I found I needed HAVE_TIMEVAL because of select, and then needed HAVE_GETTIMEOFDAY also -- HAVE_TIMEVAL was documented, but HAVE_GETTIMEOFDAY was not. There should be a canonical list of EVERY define that can be set, and when it should be set. 4) The Makefile in src also had to be edited to work properly under DG/UX because of the preprocessor. At the current time the output of the cc -E command leaves in comments, and doesn't work too well when the preprocessor is used to build the secondary makefile. We do also ship the Bell system V preprocessor as /lib/ccp, but use an integrated preprocessor in the compiler proper. 5) Finally, in src/fileio.c, the program peeks into the FILE structure. At DG stdio was done before the UNIX port, so the names don't match up (and sometimes there is no equivalent field). -- Michael Meissner, Data General Uucp: ...mcnc!rti!dg_rtp!meissner It is 11pm, do you know what your sendmail and uucico are doing?
meissner@dg_rtp.UUCP (Michael Meissner) (05/17/87)
Two final things, that are important. DG stacks grow the oppisite direction as most other UNIX machines, so there may be all sorts of assumptions about stack growth (though I suspect if it runs on a pyramid, there may not be). Also because of the segment issue and stack growth, unexec may have to be completely rewritten. At the current time, I have CANNOT_DUMP defined. -- Michael Meissner, Data General Uucp: ...mcnc!rti!dg_rtp!meissner It is 11pm, do you know what your sendmail and uucico are doing?
rbj@ICST-CMR.ARPA (Root Boy Jim) (05/18/87)
? Two final things, that are important. DG stacks grow the oppisite direction ? as most other UNIX machines, so there may be all sorts of assumptions about ? stack growth (though I suspect if it runs on a pyramid, there may not be). ? Also because of the segment issue and stack growth, unexec may have to ? be completely rewritten. At the current time, I have CANNOT_DUMP defined. Why don't you define CANNOT_COMPUTE as well? ? Michael Meissner, Data General Uucp: ...mcnc!rti!dg_rtp!meissner (Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa> Now, let's SEND OUT for QUICHE!! P.S. Zippy must have learned Pascal!
mitch@stride1.UUCP (05/21/87)
In article <8705180121.AA08181@icst-cmr.arpa.ARPA> rbj@ICST-CMR.ARPA (Root Boy Jim) writes: >? Two final things, that are important. DG stacks grow the oppisite direction >? as most other UNIX machines, so there may be all sorts of assumptions about >? stack growth (though I suspect if it runs on a pyramid, there may not be). Jim, These lines (greped) from Gnu Emacs sources should clear your doubt stack. TAGS:find_stack_direction alloca.c:#ifndef STACK_DIRECTION alloca.c:-- must know STACK_DIRECTION at compile-time alloca.c: Define STACK_DIRECTION if you know the direction of stack alloca.c: STACK_DIRECTION > 0 => grows toward higher addresses alloca.c: STACK_DIRECTION < 0 => grows toward lower addresses alloca.c: STACK_DIRECTION = 0 => direction of growth unknown alloca.c: find_stack_direction (); m-att3b.h:#define STACK_DIRECTION 1 m-gould.h:#define STACK_DIRECTION -1 /* grows towards lower addresses on Gould UTX/32 */ m-wicat.h:#define STACK_DIRECTION -1 /* grows towards lower addresses on WICAT */ Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.
throopw@dg_rtp.UUCP (Wayne Throop) (05/21/87)
> rbj@ICST-CMR.ARPA (Root Boy Jim) >> At the current time, I have CANNOT_DUMP defined. > Why don't you define CANNOT_COMPUTE as well? Ha, ha. Boy, oh boy, that Root Boy is some wit, isn't he? But, to answer the question, primarily because there isn't such an option. (I presume, if it existed, it would use portable code in place of code tailored to particular architectural assumptions.) -- "I see some people typecheck when its conveeeeeeenyunt." --- The Church Lady -- Wayne Throop <the-known-world>!mcnc!rti!dg_rtp!throopw
rbj@ICST-CMR.ARPA (Root Boy Jim) (05/27/87)
? In article <8705180121.AA08181@icst-cmr.arpa.ARPA> rbj@ICST-CMR.ARPA (Root Boy Jim) writes:
? >? Two final things, that are important. DG stacks grow the oppisite direction
? >? as most other UNIX machines, so there may be all sorts of assumptions about
? >? stack growth (though I suspect if it runs on a pyramid, there may not be).
No, rbj did not *write*, rbj *quoted*.
? Jim,
? These lines (greped) from Gnu Emacs sources should clear your doubt stack.
?
? m-att3b.h:#define STACK_DIRECTION 1
You mean TPC does it backwards too? Mind boggling!
? Thomas P. Mitchell (mitch@stride1.Stride.COM)
? Phone: (702) 322-6868 TWX: 910-395-6073
? MicroSage Computer Systems Inc. a Division of Stride Micro.
? Opinions expressed are probably mine.
(Root Boy) Jim "Just Say Yes" Cottrell <rbj@icst-cmr.arpa>
It's NO USE.. I've gone to ``CLUB MED''!!mitch@stride1.stride.COM ("Thomas P. Mitchell") (05/28/87)
Date: Wed, 27 May 87 11:53:11 EDT
From: Root Boy Jim <rbj@icst-cmr.arpa>
? In article <8705180121.AA08181@icst-cmr.arpa.ARPA> rbj@ICST-CMR.ARPA (Root Boy Jim) writes:
No, rbj did not *write*, rbj *quoted*.
Blush -- I let a program pull in your note I should have looked.
? m-att3b.h:#define STACK_DIRECTION 1
You mean TPC does it backwards too? Mind boggling!
Got me what is TPC? I do find it interesting how stuck people
can get about stack direction though. Did you see all the noise
in the minix news group a month or so ago?
Thomas P. Mitchell (mitch@stride1.Stride.COM)
Phone: (702) 322-6868 TWX: 910-395-6073
MicroSage Computer Systems Inc. a Division of Stride Micro.
Opinions expressed are probably mine.