Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!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: <1991Feb17.002458.29873@uicbert.eecs.uic.edu> Date: 17 Feb 91 00:24:58 GMT References: <1991Feb13.170045.16864@uicbert.eecs.uic.edu> <14900024@hpdmd48.boi.hp.com> Organization: University of Illinois at Chicago Lines: 64 sritacco@hpdmd48.boi.hp.com (Steve Ritacco) writes: >> I don't know if 64-bit addressing is a good idea in general, and I suspect >> it's a *bad* idea for languages like Lisp and Smalltalk, where the standard >> implementation technique is to make everything the size of a pointer, >> so that you can store either a pointer or a tagged "immediate" value >> anywhere. Going to 64-bit addresses would *double* your memory >> requirements. There are much better ways to spend transistors. [ NOTE (added later): I acknowledge Eliot Miranda's criticism of the above, that it doesn't really *double* your memory needs, just increases it by nearly 70%. That's bad enough for me... ] >This doesn't seem very well thought out to me. 64 bits is a nice healthy >amount of room for a cons cell or an immediate value. I'm not sure I get this. It sounds like you're saying you can put an immediate or a cons cell in 64 bits. But since a cons cell has two fields (CAR and CDR) that have to be able to hold tagged pointers (or immediates), a cons cell MUST be at least twice the size of a pointer. (Discounting compression schemes like cdr-coding, or my own page-fault- time compression scheme.) I agree that 64 bits is a nice size for a cons cell, but that means it's *not* a nice size for a pointer. You want 32-bit addresses so you can grab two of them at once if you have a 32-bit bus. And you want pointer swizzling to give you a large address space anyway. (And you want page-fault time compression to reduce the memory and disk requirements even further. > It was pretty common >to steal the top few(or bottom) bits of a word for a tag but with 64 bits >you can do that without sacrificing precision. What about applications of >clever crd codeing schemes which could give access to a huge address space >but efficiently describe common addresses with smaller offsets. Two-bit low tagging works great on byte-addressed machines. Any other information can always be put in object headers, rather than in pointer tags. I don't think it's a big win to have more bits available for tag use. Cdr-coding is dead because it's slow, and requires a custom architecture to support it efficiently, which Isn't Likely. (Look at Symbolics... sigh.) Page-fault time compression is better, but I still don't think you want 64-bit architectures for Lisp or Smalltalk. There's a lot of small (but nontrivial) wins from 32-bit machines instead of 64-bit machines, like larger effective on-chip cache size. Lisp and Smalltalk want *big* (and set-associative) caches. >I think 64 bits opens up a whole new world of possibilities, and we must be >careful to re-think implementations, not just re-implement them. I agree. But we also need to rethink the whole idea of 64-bit architectures. Pointer swizzling on 32-bit architectures is an idea we should look at too. [ I agree with Hugh LaMaster that you have restrictions on object sizes, i.e., gigabyte arrays cause trouble. But it's not clear that there isn't some cleverer way around that than simply doubling the word size. And it's a lot nicer than simple segmenting, for most purposes, because programs and programmers only have to see one kind of pointer, etc. And you only need a 32-bit hardware bus. ] -- 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