🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22627

Re: 64-bit addresses

#22627
From: daniel mocsny
Date: Mon, 26 Feb 1990 20:47
43 lines
2515 bytes
In article <52651@bbn.COM> lkaplan@BBN.COM (Larry Kaplan) writes:
>In article <36439@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>>No later than 1991, somebody will purchase:
>>	a) A microprocessor-based system.
>>	b) Delivered with 1GB of memory.
>>	c) And they'll really want more physical memory
>>	d) And they'll dislike an addressing limit of 2GB-4G.
>
>Too late, such a system has already been SOLD.  BBN ACI just announced ...

Now that this barrier is history, how long will we wait for the following?

1. The value of computers sold with 1 GB of physical memory to
exceed 1% of the total computer market value.

2. The above fraction to exceed 10%.

Every limit constrains *someone*, but until it constrains enough people,
industry does not respond.

I am sure that someday 2-4GB addressing limits will be constraining,
but this would seem to require major advances in software technology.
1 MB sounded like a lot back in 1980, but even then a single
programmer could readily write, from scratch, an application that
would use more memory than that. So you had a built-in barrier that
was already too low for the types of jobs people could do at the
time.

I don't know many people who can single-handedly write code that chews
up >1 GB. One way to do that is to have repetitive data structures
(e.g., arrays), but many applications are too irregular to make this
easy. The only way for most people to use up 1 GB is to have vastly
more complex software. How will we create such software? (Using CASE
tools? Organizing bigger collective code-writing efforts?
Standardizing the hell out of everything, so everybody's work can go
into everybody else's library?) Unfortunately, the complexity of
reliable software seems to be growing at best linearly with time. A
single human can only manage some roughly fixed amount of complexity,
and this fact may emerge as the limiting factor in exploiting large
address spaces.

Dan Mocsny
dmocsny@uceng.uc.edu
Technical Details
Message-ID: <3786@uceng.UC.EDU>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!cica!iuvax!uceng!dmocsny
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <36080@mips.mips.COM> <168@csinc.UUCP> <193@zds-ux.UUCP> <36439@mips.mips.COM> <52651@bbn.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!cica!iuvax!uceng!dmocsny
From: dmocsny@uceng.UC.EDU (daniel mocsny)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Message-ID: <3786@uceng.UC.EDU>
Date: 26 Feb 90 20:47:47 GMT
References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <36080@mips.mips.COM> <168@csinc.UUCP> <193@zds-ux.UUCP> <36439@mips.mips.COM> <52651@bbn.COM>
Distribution: all
Organization: College of Engg., Univ. of Cincinnati
Lines: 43