Xref: utzoo comp.lang.c:24857 gnu.emacs.bug:1470 comp.emacs:7511
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.lang.c,gnu.emacs.bug,comp.emacs
Subject: Re: GNU Emacs, memory usage, releasing
Message-ID: <1990Jan3.151427.12532@ux1.cso.uiuc.edu>
Date: 3 Jan 90 15:14:27 GMT
References: <1558@aber-cs.UUCP> <32534@news.Think.COM> <S_W2=5ggpc2@ficc.uu.net> <1990Jan2.151615.19098@talos.uu.net> <USER.90Jan3094015@pmax27.osf.org>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: Univ. of Illinois at Urbana-Champaign, Chemical Sciences
Lines: 41

In article <USER.90Jan3094015@pmax27.osf.org> USER@osf.org (Michael Meissner) writes:
>In article <1990Jan2.151615.19098@talos.uu.net> kjones@talos.uu.net
>(Kyle Jones) writes:
>
>| It's not really accepted as much as it's tolerated, simply because the
>| vast majority of Emacs users are not inconvenienced by the 16Mbyte
>| limit.  (Leonard Zubkoff pointed out only 5 type bits are actually
>| needed currently, so Emacs can be compiled to handle 64 Mbytes of memory
>| before it dies.)  If I had been in on the early development of GNU Emacs
>| I would have indeed screeched and howled about the pointer munging.
>| But as it stands now, the inconvenience of the memory limitation is far
>| outweighed by the work necessary to fix the problem.
>
>When I started working with GNU C, I noticed a synergy (sp?) between
>the GNU C compiler and emacs.  As has been pointed recently, the top
>byte on big endian systems, and the bottom byte on little endian
>systems is used to hold the type stuff (and the mark bits during
>garbage collection).  Anyway, the machine descriptions that I looked
>at had optimizations to do a load byte, rather than a load word and a
>shift.  Since a lot of the emacs lisp interpreter is looking at the
>type field, this can eliminate extra instructions in the code.
>
This seems to me to be disgusting. Why not just define these
"things" (the pointer with 8 bits of something else stuck in somewhere)
as 

struct THING {
char * ptr;
char tag;
}

?   
What will happen to the original method on machines that NEED a
full 32 (or 16 or 36) bits for a pointer (segmented architectures,
or 36 bit architectures)?  Won't it fail to compile?

This sort of stuff seems to indicate that Gnu software, at least this
part, is pooorly designed. Some of the Gnu stuff I have ported to my
PC has been among the worst C code I have seen. 

Doug McDonald