Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!gatech!mcnc!rti!dg_rtp!meissner
From: meissner@dg_rtp.UUCP (Michael Meissner)
Newsgroups: comp.emacs
Subject: Re: GnuEmacs on Data General ?
Message-ID: <1922@dg_rtp.UUCP>
Date: Sun, 17-May-87 10:35:48 EDT
Article-I.D.: dg_rtp.1922
Posted: Sun May 17 10:35:48 1987
Date-Received: Sun, 17-May-87 19:40:55 EDT
References: <1574@umn-cs.UUCP>
Reply-To: meissner@dg_rtp.UUCP (Michael Meissner)
Distribution: world
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 61

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?