peter@ficc.uu.net (Peter da Silva) (01/01/90)
In article <32534@news.Think.COM> rlk@think.com (Robert Krawitz) writes: > 2) Emacs dies very quickly after its virtual size exceeds 16 Mbytes, This is a scary thought all by itself, but... > due to the 24 bit pointers used (the top 8 bits are used as tag bits for > the Lisp interpreter). Come *ON*, why is this accepted? I remember not so very long ago people were flaming Microsoft for doing this on the Macintosh, which led to Microsoft applications not working on >1MB machines after the extra bits started getting decoded... Not to mention that making assumptions about pointer formats is dangerous in and of itself. Certainly you can't *use* such pointers without stripping them, which adds overhead to every memory reference. And (per recent discussions in comp.std.c) there are architectures out there that won't even let you load them into an address register. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
kjones@talos.uu.net (Kyle Jones) (01/02/90)
Robert Krawitz writes: > 2) Emacs dies very quickly after its virtual size exceeds 16 Mbytes, > due to the 24 bit pointers used (the top 8 bits are used as tag bits for > the Lisp interpreter). Peter da Silva writes: > Come *ON*, why is this accepted? I remember not so very long ago > people were flaming Microsoft for doing this on the Macintosh, which > led to Microsoft applications not working on >1MB machines after the > extra bits started getting decoded... 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.
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 <S_W2=5ggpc2@ficc.uu.net> peter@sugar.lonestar.org (Peter da Silva) writes: >Not to mention that making assumptions about pointer formats is dangerous in >and of itself. Note that Gnu Emacs doesn't do this. It uses macros to extract pointers from tagged words. On reasonable machines, these macros are trivial. On unreasonable machines, they are more complex. -- 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
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