Xref: utzoo comp.sys.ncr:532 comp.arch:18429 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!metro!usage.csd.unsw.oz.au!syacus!william From: william@syacus.acus.oz (William Mason) Newsgroups: comp.sys.ncr,comp.arch Subject: Re: Terradata architecures Keywords: YNet Bus, CTOS, X-Bus, Megaframe, RPC, NGEN, BTOS, STAROS, BULL, irony Message-ID: <1098@syacus.acus.oz> Date: 5 Oct 90 17:40:30 GMT References: <211@bilpin.UUCP> <1990Sep28.020717.22610@dhw68k.cts.com> <1990Oct1.200613.635@tera.com> Organization: Australian Centre for Unisys Software, Sydney Lines: 67 cc: william@syacus doc@tera.com (Dan Cummings) writes: >In <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes: >>I'd be pretty amazed to see a massively parallel computation system built >>up with busses. That contention problem is a giant killer, and that's >>why message-passing scalar systems are kicking butt, even if they are >>a bit tougher to built software. Shared memory systems are technological >>dinosaurs. > >Shared memory systems are hardly technological dinosaurs. The fact >that bus contention becomes unmanageable in large systems just means discalimer: irony deliberate ... don't worry yanks] ... IF ... someone could allow themselves some free-range thinking, for just a minute. Then, we could stop fighting about whether bus-ed is better than shared memory and where the meaning of life begins and wanking starts. What I would like to see is a calling protocol that is independent of the hardware _CONSTRUCTION_ [emphasis deliberate]. Having examined things like NFS(tm?) and NetWise(tm), etc. and various other (as I'd like to *see*) "distributed load system"-s. I have come to the conclusion that any SYSTEM architecture not based on and RPC (Remote Procedure Call) mechanism is liable to become the next epoch's coal and shale {look it up}. OK ... How one *does this* can be arguable non-trivial at the hardware level. But how many machines do allow for/provide such functionality ? Once done, the possibilities become endless. Especially now with the expansion of networking ! For one: the Object Oriented paradygm more or less assumes that an method [Parc] "sees" it's owner's context. This may be/is often disjoint from a stack based architecture. Also, if/when we {the *softies*} wish to provide services like {ISO}ACSE/ROSE/etc. then we invent clumsy/ugly implementations (c.f. the AT&T(tm) ACSE/ROSE stuff). I should admit to my (own) software bias ... I feel that the real challenges in computer architecture will be provided at an RPC level. Like ... * Name server vs. Operations/function Servers. * An agent--Server arch. vs. a Request+Broardcast architecture. * What does one do with conection oriented operations (Open_()) and connectionless things like "wait()" ? * What happens is a server's client "dies" !? * Reat-time vs. Datagram. * Integrated R/t and D/g. And what about that archane(sp?) concept of call-by-name, somehow this seems to gain new *meaning* in a . All of this is a supplication for the HW-persons out-there to at least consider the needs of more advanced software thinking. I'm (now) working on a machine that has been using RPC for its bread+butter for over 10 years (it is 1990 ? nee). The Japanese are doing it better(?) with the TRON Project. While people are still arguing 10/20-year old questions like is bus better than shared memory ? punch-line: forget "stack frames" try for "RPC-frames". Respectfully yours, William Mason : william@syacus : disclaim { gee, I they asked ... this is : ACUS r+D, Syd : what I'd say. But, who listens ? +61 2 476 1217: Australia. : }