Path: utzoo!attcan!uunet!cs.utexas.edu!jarvis.csri.toronto.edu!jonah
From: jonah@db.toronto.edu (Jeffrey Lee)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Message-ID: <90Feb13.145335est.2864@ois.db.toronto.edu>
Date: 13 Feb 90 19:53:49 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> <WAYNE.90Feb11165528@dsndata.uucp> <3606@uceng.UC.EDU> <757@dgis.dtic.dla.mil>
Organization: University of Toronto, CSRI
Lines: 42

jkrueger@dgis.dtic.dla.mil (Jon) writes:
>Sounds pretty scary.  Now, you'd never guess it from what appears
>in comp.arch, but the chief use of cycles is pushing around 8 bit
>unsigned quanitities that by convention stand for printable symbols
>representing a curious code called the "alphabet".

Or at least until a few years ago.  Now most of the machines that I use
spend most of their time pushing around 1 to 32 bit unsigned quantities
that by convention stand for "pixels" so that *I* can spend most of my
time shuffling printable symbols representing a curious code called the
"alphabet".

>                                                    So my challenge
>to you (or anyone) is to tell me what your word processing would do
>with 32+ addressing bits?  Ground rules: no Emacs jokes, can only
>include the space costs of support tools when clearly part of the
>word processing, and no credit for mere time advantages.  Well?

Picture a "docuverse" [TM Xanadu Corp.] where all the machine readable
text in existence can be mmap()ed into your address space.  Mind you
even 64-bits isn't enough -- which is why Ted Nelson dreamed up
"tumblers" [Thedore H. Nelson, "Managing Immense Storage", in BYTE,
January 1988, pp225-238].  Why isn't 64-bits enough?  Because it only
allow for 4GB of shared "global" space per Internet host.

More plausibly, shared virtual address spaces (or *shudder* segments)
may allow programs and processors to exchange data with something akin
to a page-level equivalent of memory caching.  The word processor of
the future will *not* stand alone, but will be an integrated piece of
your environment -- potentially communicating with anything that wants
to edit or display text.  To which end, we need to ensure that the
systems of the future can support the following *very* cheaply:

	multi-processing and context switching
	inter-process communication / remote procedure calls
	"network services"

Of these, multi-processing and context switching, and IPC / RPC appear
to be comp.arch issues.  The use of a shared 64-bit address space is
merely one approach to IPC.

Jeff Lee -- jonah@cs.toronto.edu