Path: utzoo!attcan!uunet!munnari.oz.au!sirius.ucs.adelaide.edu.au!hydra!francis From: francis@cs.ua.oz.au (Francis Vaughan) Newsgroups: comp.arch Subject: Re: >32 bits Message-ID: <1686@sirius.ucs.adelaide.edu.au> Date: 25 Oct 90 05:04:01 GMT References: <1990Oct25.011034.3664@ingres.Ingres.COM> Sender: news@ucs.adelaide.edu.au Reply-To: francis@cs.adelaide.edu.au Organization: Adelaide Univerity, Computer Science Lines: 35 Nntp-Posting-Host: hydra.ua.oz.au In article <1990Oct25.011034.3664@ingres.Ingres.COM>, jpk@ingres.com (Jon Krueger) writes: |> From article , by aglew@crhc.uiuc.edu (Andy Glew): |> > Occasionally this group discusses whether there is a need for |> > computers with >32 bits of address space.... |> > People already have databases that exceed 32 bits worth of address if |> > memory mapped. |> |> Just to play devil's advocate, why use the processor to address |> persistent, shared data objects? The processor is designed to address |> objects that live in volotile store, exist for the lifetime of a |> process, and are private to that process. The database engine is |> designed to address persistent, shared, objects. The database engine |> uses processors, but it doesn't depend on particular processor's |> address space. |> |> Well? Funnily emough there are groups (well group) doing just this. The MONADS project at the University of Newcastle, Australia does basicly what you describe. 128 bits of object ID but mapped down to 32 bits for use by an off the shelf processor (SPARC in the machine currently being designed). Maybe someone from Newcastle would care to comment, I'm sure someone is reading. Note however that orthogonal persitence requires that ANY object may become persistent, the fact that an object comes into being in volatile store should not require special action on the part of the programmer to make it persistent. From the point of view of the execution engine there is no distinction between persistent and volatile data. Francis Vaughan.