Re: Ada Annex E (Just curious :-)

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

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" <rigotti@atc.dera.gov.uk> 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
>
>