Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson From: wilson@uicbert.eecs.uic.edu (Paul Wilson) Newsgroups: comp.arch Subject: Re: Swizzling (very RISC) instead of 64 bits (was Re: 64 bit addresses) Message-ID: <1991Feb18.031318.16279@uicbert.eecs.uic.edu> Date: 18 Feb 91 03:13:18 GMT References: <1991Feb13.170045.16864@uicbert.eecs.uic.edu> <3341@sequent.cs.qmw.ac.uk> Organization: University of Illinois at Chicago Lines: 80 pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >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: That's not what I was talking about. I *wasn't* talking about only being able to allocate memory in pair-sized units. (My own garbage collector certainly doesn't have this limitation -- see my 1989 OOPSLA paper if you're interested.) I was just saying that pairs have to be able to hold two pointers, so that (barring compression), they have to be bigger than the pointer (address) size. Twice as big or more, in the general case. So you can use 64-bit pairs, or 64-bit pointers, but not both. Eliot is still right, however, that some objects (like string and bitmap objects) contain fields that can't hold a pointer. This is a ubiquitous efficiency hack. These objects therefore needn't expand, so we don't really double memory requirements. >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. Them's fightin' words :-) >*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. Right, sharing is comparatively rare, but when it's used, it's *very* *very* useful. The nice thing is that you don't have to rewrite your code if you decide something should be shared -- you don't have to "de-inline" it. It's no concidence that the first gc'd language (LISP), and the most completely object-oriented languages (Smalltalk and Self) have uniform-sized value cells for most purposes, into which you can shove pretty much anything. Even strongly-typed polymorphic languages tend toward this. It's handy to be able to change sharing patterns when you need to, without redefining all of your object types to un-inline their components. You can write much more general and reusable code. An object is an object is an object (and other hype). This is not to say I'm against contiguous compound objects; I'm just saying they have a downside in terms of generality. >eliot> That was fun :-) >Not just fun, terribly useful. Both the data and the calculations. >Thanks for both. Yes, thanks. >-- >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 -- Paul -- Paul R. Wilson Software Systems Laboratory lab ph.: (312) 996-9216 U. of Illin. at C. EECS Dept. (M/C 154) wilson@bert.eecs.uic.edu Box 4348 Chicago,IL 60680