mcdonald@aries.scs.uiuc.edu (Doug McDonald) (01/03/90)
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
kjones@talos.uu.net (Kyle Jones) (01/05/90)
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.
richard@aiai.ed.ac.uk (Richard Tobin) (01/06/90)
In article <1990Jan3.151427.12532@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > 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; > } Because this will typically make each THING take up twice as much space, which is often unacceptable. If portability is more of a concern than speed, one approach is to use bitfields and treat the "address" as an array subscript. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin