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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd0ee7c9be011576 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-06 13:16:10 PST Path: supernews.google.com!sn-xit-03!supernews.com!newsfeed.wirehub.nl!newspeer.monmouth.com!dispose.news.demon.net!demon!nntp.news.xara.net!xara.net!gxn.net!nntp.netconnect.net.uk!news.lattis.xara.net!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada Annex E (Just curious :-) Date: Tue, 6 Mar 2001 15:56:53 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <983ivv$r8c$1@nh.pace.co.uk> References: <3AA29386.E60A686D@linuxchip.demon.co.uk> <980ekl$p4h$1@nh.pace.co.uk> <3AA43C58.105B970D@linuxchip.demon.co.uk> <982veb$l62$1@nh.pace.co.uk> <983b1s$m6h$1@trog.dera.gov.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 983912255 27916 136.170.200.133 (6 Mar 2001 20:57:35 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 6 Mar 2001 20:57:35 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:5478 Date: 2001-03-06T20:57:35+00:00 List-Id: I think we're talking about two different problem spaces. I was thinking in terms of some of the DoD applications I've seen where you have a box that is a custom one-off kind of doohickie that isn't built out of standard off-the-shelf components. This is when you are writing your own OS in effect and you have to deal with some pretty primitive levels of the hardware. Picture if you will a bare piece of circuit board material to which you glue a handfull of different processors. (A couple of standard workhorse processors, a DSP, maybe a graphics processor, etc. Look at what you have lying around on the workbench and go with it! :-) Glue down some EEPROM and RAM for each of these guys. Glue down some EEPROM and RAM for them to share. Make some random foil traces until the lights start to blink. Now you've got a basic military custom computer - perhaps for a space mission or a smart weapon guidance thingie or something like that. Chances are, you're going to end up using different compilers for each of the processors - maybe not even the same language. In this sort of situation, it would be difficult to imagine an Ada compiler providing you (for example) Annex E support for your shared memory without some kind of customization - let alone figuring out how to make an RPC to a different processor. Your garden variety Ada compiler may support Annex E in some respect and theoretically be able to help you share memory or devices in this environment. The problem is that because you have no OS and you may not even have similar processors, you're not going to get the distribution features of Annex E unless someone goes and modifies the compiler to use whatever it is you've got to do the communications. That never comes free - or even cheap - so chances are you aren't going to be able to take advantage of Annex E. You'll have to build your own facilities, perhaps at the bare-silicon level in some manner, just to get things talking to each other. The compiler isn't going to understand those mechanisms automatically, so it can't use them to stack up the data and make a remote procedure call. You'll have to "roll-your-own" in some way. Maybe the BSP thingie suggests a style of "rolling-your-own"? It could be useful, but it doesn't address how to take advantage of Annex E in this sort of environment. (And, of course, you've got latency and efficiency concerns mentioned in other posts...) Certainly, when you're talking about a group of workstations wired together with TCP/IP - or some off-the-shelf processor boards with an RTOS that supports TCP/IP, you might expect the compiler to be able to give you some help here with distribution. Without those, or similar mechanisms though, I don't know how one would do that..... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Kevin Rigotti" wrote in message news:983b1s$m6h$1@trog.dera.gov.uk... > I'm speaking from a position of ignorance, having never done it, but perhaps > BSP (http://www.bsp-worldwide.org/) style distributed processing would be > useful? > > Namely, all non-local read and write requests queued locally until the end > of the super-step, then completed by message passing using "Annex E > mechanisms". There would be no need for that to be homogenous. > > If one partition were set up as controller, and each of the others > registered themselves with it on startup then it would be easy enough to > give everything a vector of access values for remote dispatching to the > other components. > > What you *do* need for any BSP-like thing is an efficient way of doing > multicast messaging and n-way rendezvous. I'm not at all clear on how to do > that efficiently in Ada. > > If the application had sufficiently many natural synchronisation points then > deferring the communication wouldn't be too expensive, and performance would > at least be predictable if not actually scalable. > > Maybe? It's something I've wanted to play with but never had the time or > funding for :-) > > Kevin > -- > ATC Systems Group, DERA, St Andrews Road, Malvern, Worcestershire WR14 3PS, > UK > Phone +44 (0)1684 89 69 11, fax +44(0)1684 89 41 09 > DERA disclaimers and restrictions apply, details on request > >