Xref: utzoo comp.lang.c:24884 gnu.emacs.bug:1479 comp.emacs:7521
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!talos!kjones
From: kjones@talos.uu.net (Kyle Jones)
Newsgroups: comp.lang.c,gnu.emacs.bug,comp.emacs
Subject: Re: GNU Emacs, memory usage, releasing
Message-ID: <1990Jan4.170957.16771@talos.uu.net>
Date: 4 Jan 90 17:09:57 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> <1990Jan3.151427.12532@ux1.cso.uiuc.edu>
Lines: 23

Doug McDonald writes about the pointer munging in GNU Emacs:
 > 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;
 > }
 > 
 > ?

Memory savings.  By making packing the type and garbage collection mark
bits into an object pointer, you get considerable saving per object.
That extra char for the tag can cost one to three extra bytes of storage,
due to the padding needed within the struct.

 > 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?

Emacs could probably run on 36-bit machines, given the appopriate config
files.  16-bit machines can forget it, though.