From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-03 11:15:56 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "M. A. Alves" Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS Date: Mon, 3 Sep 2001 19:16:11 +0000 (GMT) Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: avanie.enst.fr 999540954 54475 137.194.161.2 (3 Sep 2001 18:15:54 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 3 Sep 2001 18:15:54 +0000 (UTC) To: Return-Path: X-X-Sender: In-Reply-To: <3b913376.333516@news.cis.dfn.de> Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:12665 Date: 2001-09-03T19:16:11+00:00 > >But why limit a file to an array of storage elements? Why not persistant > >unbounded storage pool? Or persistant unbounded tagged classwide type? > >Or persistant protected object? (Ada already has the concept of a > >persistant storage mechanism, pragma shared_passive. Why not use that?) > > Amen. > > I would like to add, why to have files at all? There should be only > objects allocated in one big virtual memory chunk. 64-bit address > space allows to address every objects in every computer of the world. > There should be no I/O, only memory mapping. Yes! With each memory cell classified according to: * readable or not * writeable or not * timeable access or not (for real time computations) * persistency * ... With the proper methods and exceptions e.g. Put, Get, Read_Error, etc. Some mixin, it appears. You still have _devices_. All cells in the same device would have the same class(ification). In fact all there is is devices, not computers, as a computer is a set of devices. So each device in the world would have an id (some already do) and so each cell in the world has id (device_id, cell_number) or so. But a 50/50 partition of the 64-bit addressing gives c. 1 million devices with 1 million cells each: not enough. Go for 128-bit, 1 billion devices of 1 billion cells each. And I feel even that is a bit tight. 256-bit? Now, "mapping". The OS would have device interfaces (libraries), and an "overall" layer providing the universal mapping. -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150 PORTO, Portugal mob 351+939354002