Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Swizzling (very RISC) instead of 64 bits (was Re: 64 bit addresses) Message-ID: Date: 15 Feb 91 15:54:54 GMT References: <1991Feb13.170045.16864@uicbert.eecs.uic.edu> <3341@sequent.cs.qmw.ac.uk> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 50 Nntp-Posting-Host: odin In-reply-to: eliot@cs.qmw.ac.uk's message of 14 Feb 91 21:02:19 GMT On 14 Feb 91 21:02:19 GMT, eliot@cs.qmw.ac.uk (Eliot Miranda) said: eliot> In article <1991Feb13.170045.16864@uicbert.eecs.uic.edu> eliot> wilson@uicbert.eecs.uic.edu (Paul Wilson) writes: wilson> I don't know if 64-bit addressing is a good idea in general, and wilson> I suspect it's a *bad* idea for languages like Lisp and wilson> Smalltalk, where the standard implementation technique is to wilson> make everything the size of a pointer, so that you can store wilson> either a pointer or a tagged "immediate" value anywhere. Going wilson> to 64-bit addresses would *double* your memory requirements. Not quite, the problem is rather with *some* Lisp implementations that do use pair-sized cells for everything. Many Lisps (for example those built with copying collectors can do it easily) also use variable sizes allocations, with very small overheads, and all Smalltalk systems use variable sized segments as explained below: eliot> In a rather pedantic mode (appologies all) this is not quite so! eliot> In typical Smalltalk-80 systems many objects are bit objects eliot> (e.g. strings, symbols, bytecodes, bitmaps). When Smalltalk-80 eliot> implementations went from 16-bit pointers to 32-bit pointers the eliot> standard V2.0 image file grew from 598016 bytes (seriously eliot> folks!) to about 1 megabyte. eliot> [ ... assume pointers, headers, etc double in size but not eliot> variable sized segments, then get data and so calculations ... ] eliot> an expansion of 1.68. (Which is depressingly close to 2). eliot> [ ... but actually one could have as immediate values small sized eliot> segments, so with more data and calculations ... ] now expansion eliot> is from 2092160 to (3515002-265352) which is a factor of 1.55. Actually these large expansion factors (not quite 2, but as you remark fairly large) need not apply everywhere. Smalltalk regrettably is (like virtually every other OO or 'AI' language) reference based. If it *allowed* object composition by contiguity instead as well, as most less advanced languages do, then many less pointers would be needed. Some statistics show that sharing of subobjects is fairly rare is some major applications, so they could be profitably inlined. eliot> That was fun :-) Not just fun, terribly useful. Both the data and the calculations. Thanks for both. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk