Path: utzoo!attcan!telly!lethe!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: Swizzling (very RISC) instead of 64 bits (was Re: 64 bit addresses) Message-ID: <1991Feb13.170045.16864@uicbert.eecs.uic.edu> Date: 13 Feb 91 17:00:45 GMT References: Organization: University of Illinois at Chicago Lines: 73 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. It's possible to implement 64-bit (or 100 bit, or whatever) addresses efficiently on standard 32-bit hardware by performing address translation at _at_page_fault_time_ -- you "swizzle" (translate) big addresses into small ones so that running programs only ever see "normal" hardware-supported addresses. This scheme *can* support more RAM than the addresses specify, if you use a kind of page-switched architecture. (A form of bank switching, where every RAM page knows whether it is mapped into the address space, and where.) Programs (and programmers) don't have to see this page-switching. Pointers are swizzled and pages are switched at page-fault time. (This scheme is a recent development, and wasn't in the tech report on swizzling that I sent out to a lot of people who requested it.) [By the way, everybody who asked more than a week ago -- 75 people! -- should have gotten it by now.] With swizzling, you run out of address space every now and then (after touching around a gigabyte or so of pages), and you have to use faulting to re-map memory. There's some overhead at page fault time, but it's not like a real disk seek. It's probably not a lot, especially if there's any reasonable locality, since then you don't really do it that often compared to the huge number of instructions you're executing in between. This can be seen as the RISC philosophy applied to address translation. Usually there's enough locality that a 32-bit address can specify plenty of locations to keep the processor happy. Every now and then, you have to adjust the address space seen by the 32-bit processor (so that it can actually see more memory than that). You *don't* do it by just making the processor bigger and fatter, you do it by handling the unusual case in software. For Lisp & Smalltalk, even if you have a 64-bit bus, I suspect you'd be *much* better off fetching two 32-bit words (e.g., whole cons cells) at a time. As for type tags, using the two low-order bits as a tag works fine if you put the rest of the type information in object headers; that's how most people do it now. Big-bag-of-pages schemes are not so popular, partly because they make a generational garbage collector a lot more complicated. Even if you can afford 64-bit chips, you may not want them. A 32-bit chip can probably be made faster, if only by using faster materials with a lower level of integration. The extra overhead for the occasional swizzling and page-switching is probably well worth it. I'm not really clear on what the "optimal" hardware address size is, but I'd bet that for Lisp and Smalltalk, it's *not* 64 bits. Of course, if you want a bunch of bits to specify a huge number of addresses across a parallel machine, you may want larger addresses; but then you're really using a lot of those bits as processor numbers. -- 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 -- 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