Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rti-sel.UUCP
Path: utzoo!linus!decvax!mcnc!rti-sel!shaddock
From: shaddock@rti-sel.UUCP (Mike Shaddock)
Newsgroups: net.emacs
Subject: Re: gnu design question
Message-ID: <590@rti-sel.UUCP>
Date: Wed, 1-Jan-86 14:23:52 EST
Article-I.D.: rti-sel.590
Posted: Wed Jan  1 14:23:52 1986
Date-Received: Thu, 2-Jan-86 05:06:31 EST
References: <21@cornell.UUCP>
Reply-To: shaddock@rti-sel.UUCP (Mike Shaddock)
Followup-To: net.emacs
Distribution: net
Organization: Research Triangle Institute, NC
Lines: 76
Keywords: portability
Summary: 

In article <21@cornell.UUCP> jqj@bullwinkle writes:
>From: jqj@bullwinkle (J Q Johnson)
>
> ... Here jqj talks about the initial design goals of C, the rise of
>     alloca(), and the problems of porting GNU Emacs to a Gould PN
>     machine.

I too am trying to port GNU Emacs 16.60 to a Gould machine, and have
run into some of the problems mentioned here.  I have stopped working
on it for the time being, but have decided that several unfortunate
design decisions were made:

  (1) Non-portable use of alloca.
      As pointed out, alloca will not work on machines without stack
      and frame pointers.  When I pointed this out on the GNU Emacs
      mailing list, the response was that alloca "was used because it
      was good for GNU, that GNU would have alloca, and that the author
      did not intend support machines that were deficient in important
      features such as not having stack and frame pointers".
      According to some people very familiar with Gould machines,
      implementing a full alloca would be very, very hard, and
      certainly not worth the time for one program.

  (2) Use of setjmp/longjmp.
      GNU Emacs uses setjmp/longjmp in several places, when it would
      have been more portable (and more correct in a pure theoretical
      sense) to return error codes, etc. instead of just jumping to
      some other place in the program.

  (3) Implementation of Lisp_Objects
      Why wasn't a simple structure, such as

	typedef struct {
	    char *multiple_things;
	    char type;
	} Lisp_Object;

	or

	/*
	 * No flames if this is slightly incorrect, I
	 * avoid using unions and am not up on the syntax
	 */
	typedef struct {
	    union {
		    /* Put all the different things */
		    /* a Lisp_Object can be here */
	    } foo;
	    char type;
	} Lisp_Object;

      used instead this rather gross way of hacking on an int?  What
      would happen if a pointer needed more than the 24 bits that it
      gets in the int?  This may be handled correctly (I couldn't
      determine that from the code), but it would certainly be a little
      less obscure to use a structure.  Some places in the code seem to
      *depend* on Lisp_Objects being ints, so it is non-trivial to
      change this for a particular machine.

  (4) Unexec
      Use of unexec is a gross hack merely for a little efficiency.

Given sufficient time I could probably re-write enough of GNU Emacs to
fix these problems, but I have neither the time nor the inclination to
do so.  Some of these complaints may be answered in the newest version
of GNU Emacs, but I have a copy of 17.31 and it doesn't look like it.
GNU Emacs seems to be a very good program from the user's point of
view, and could increase people's productivity, but I'm afraid that the
attitude of some of the people involved with GNU may be its downfall.
Portability is an important issue, and unless GNU, including GNU Emacs,
is highly portable, I'm afraid that it won't be a successful as it
should.
-- 
Mike Shaddock		{decvax,seismo,ihnp4}!mcnc!rti-sel!shaddock

"You're in a twisty maze of sendmail rules, all obscure."