Re: Ada Annex E (Just curious :-)

Re: Ada Annex E (Just curious :-)

[Marc A. Criley]

Frank wrote:
> 
> Hi!
> 
> I have read a bit in the Annex E.
> Could someone refer me to a example source code? Most preferably not an
> example larger than
> "send an integer from one partition to another that prints it on screen" or
> something like that :-)
> otherwise the issue will boil out in business complexity of some kind:-))

If you're using GNAT, download and install the associated Annex E
implementation, GLADE (all available as RPMs at the Ada for Linux site,
www.gnuada.org).  The GLADE distribution provides several basic
examples, and they _do_ work! :-)

> And also a link or example on how partitions are set up?

Download GLADE and RTFM.

> 
> Would like to try it in Linux RedHat6.2 with gnat 3.13 (if feasible :-)

Feasible, _and_ effective! :-)

> 
> As I already am writing a question here:-)
> I have also read abot ADEPT, but the info seems old, and only for Sun.
> Does any similar interface solution exist for Linux for Ada to Java?

I haven't looked at ADEPT in a long time, so I can't speak to that.  I
have had success using the AdaSockets collection on the natively
compiled Ada side, and the Socket class on the Java side (actually
JGNAT).  One does have to worry about host vs network byte order, and
what I've gotten so far is probably horribly non-portable, but for now
anyway it's working.

> 
> Frank

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Ada Annex E (Just curious :-)

[Frank]

Hi!

I guess it some kind of CORBA that is the solution for this kind of problem
then?

Frank

>
> I haven't looked at ADEPT in a long time, so I can't speak to that.  I
> have had success using the AdaSockets collection on the natively
> compiled Ada side, and the Socket class on the Java side (actually
> JGNAT).  One does have to worry about host vs network byte order, and
> what I've gotten so far is probably horribly non-portable, but for now
> anyway it's working.
>

Re: Ada Annex E (Just curious :-)

[Robert Spooner]

I made my own bindings to sockets routines before AdaSockets was
available, and at least for Unix (Solaris) and VxWorks I was able to put
all the operating system dependent information in a single package body
where I defined a few constants such as the mask size for Select.  It
should also work for VMS if you want to use sockets rather than the QIO
interface.  I haven't looked at Windows closely enough to comment on how
different the sockets interface is for it.

You can know what to do about network order for parameters by testing
the Bit_Order attribute of a type with default bit ordering, so that
shouldn't be a portability issue.

Bob

Frank wrote:
> 
> Hi!
> 
> I guess it some kind of CORBA that is the solution for this kind of problem
> then?
> 
> Frank
> 
> >
> > I haven't looked at ADEPT in a long time, so I can't speak to that.  I
> > have had success using the AdaSockets collection on the natively
> > compiled Ada side, and the Socket class on the Java side (actually
> > JGNAT).  One does have to worry about host vs network byte order, and
> > what I've gotten so far is probably horribly non-portable, but for now
> > anyway it's working.
> >

-- 
                            Robert L. Spooner
                     Registered Professional Engineer
                       Associate Research Engineer
                  Intelligent Control Systems Department

         Applied Research Laboratory        Phone: (814) 863-4120
         The Pennsylvania State University  FAX:   (814) 863-7841
         P. O. Box 30
         State College, PA 16804-0030       rls19@psu.edu

Re: Ada Annex E (Just curious :-)

[Robert Spooner]

Simon,

Simon Wright wrote:
> 
> Robert Spooner <rls19@psu.edu> writes:
> 
> > You can know what to do about network order for parameters by
> > testing the Bit_Order attribute of a type with default bit ordering,
> > so that shouldn't be a portability issue.
> 
> I would have used System.Default_Bit_Order -- is there a reason why
> not?
Actually, that would be better.  I just didn't see it when I did a
search of the LRM on line.
Bob
-- 
                            Robert L. Spooner
                     Registered Professional Engineer
                       Associate Research Engineer
                  Intelligent Control Systems Department

         Applied Research Laboratory        Phone: (814) 863-4120
         The Pennsylvania State University  FAX:   (814) 863-7841
         P. O. Box 30
         State College, PA 16804-0030       rls19@psu.edu

Re: Ada Annex E (Just curious :-)

[Pascal Obry]

"Frank" <franjoe@frisurf.no> writes:

> Hi!
> 
> I have read a bit in the Annex E.
> Could someone refer me to a example source code? Most preferably not an
> example larger than
> "send an integer from one partition to another that prints it on screen" or
> something like that :-)

Ok, what about an Hello World example ?

Client partition:

        with Message;
        with Ada.Text_IO;

        procedure Hello is
        begin
           Ada.Text_IO.Put_Line (Message.Hello_World);
        end Hello;

Server partition:


        package Message is

           pragma Remote_Call_Interface;

           function Hello_World return String;

        end Message;


        package body Message is

           function Hello_World return String is
           begin
              return "Hello World !";
           end Hello_World;

        end Message;

Configuration script:


        configuration Dist is

          pragma Starter (None);

          pragma Boot_Location ("tcp", "mycomputer:5557");

          Client : Partition;

          procedure Hello is in Client;

          Serveur : Partition := (Message);

        end Dist;

As you see the only "Annex E" specific feature here is the pragma
Remote_Call_Interface. The very same program can be built as a non distributed
application with:

        $ gnatmake hello

Of course this is only the visible part of the iceberg !!! The Annex E is
really powerfull. The mode above is a "distributed" one. But you can also
build client/server applications. The server is alive and does not stop after
the communicating with the client.

I've built some medium client/server applications with GLADE and must say that
I'm always amased by this technology. I'm not a netw<ork expert and found it
very nice that all the network trick (stub, skeleton, parameter passing...)
are done transparently. This way you can concentrate on your problem...

> otherwise the issue will boil out in business complexity of some kind:-))

I understand but as I said the Annex E is really big. For example I have done
a simple Chat program, it is a small program and very easy to understand.

> And also a link or example on how partitions are set up?

See above.

> 
> Would like to try it in Linux RedHat6.2 with gnat 3.13 (if feasible :-)

Of cource !

> As I already am writing a question here:-)
> I have also read abot ADEPT, but the info seems old, and only for Sun.
> Does any similar interface solution exist for Linux for Ada to Java?

Yes ADEPT is old. The right choice is GLADE.

Now I'm still wondering why no other Ada vendors have implemented this Annex ?
This is a real plus for Ada... Of course they will say that there is no market
for that... But sometime verdors should "push" the market, at least that easy
to say :)

Pascal.

-- 

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Re: Ada Annex E (Just curious :-)

[Dr Adrian Wrigley]

Pascal Obry wrote:
...
> Ok, what about an Hello World example ?
...

I tried this example.  It worked, but I have a few questions:

1)  If I set the Starter to "Ada", it runs fine with Client and
Serveur on the same machine, but it won't start up the remote machine.
The client simply waits indefinitely.  The remote machine and the
local machine trust each other.

2)  If I set the Starter to "Shell", I get the following:

gnatdist: generating starter hello
gnatdist: *** unknown error

raised STORAGE_ERROR : stack overflow (or erroneous memory access)
(RedHat6.2/gnat-glade-3.13p-5.i386.rpm)

3)  The client takes about three seconds to exit after printing
the message.  Why so slow?  How can I improve this?

4)  The client/server bandwidth seems very slow and CPU intensive.
For example, when I make the message return a 100_000 character
string, it takes about 500ms of processing.  How can I improve this?

5)  What are people *actually using* this technology for?
Flight control? Banking? Scientific computing?  What example
real projects are there?  Is it for performance? reliability?
controlling many remote peripherals? real-time?
Is it generally homo- or heterogenous?

I would like to use something like this for programming a
processor farm of commodity PCs, but this is tricky if the
bandwidth can't be improved.

6)  Is there a ready-built version for use with Windows/NT?

Some of these issues (3, 4, 5) are touched upon in the documentation,
but I want to know if I am missing something!

Aside from these issues, my first impression is that Annex E
is "cool", easy to use and effective... all I need now is an application
that would benefit significantly from it.
--
Adrian Wrigley

Re: Ada Annex E (Just curious :-)

[Ted Dennison]

In article <3AA29386.E60A686D@linuxchip.demon.co.uk>, Dr Adrian Wrigley says...
>
>5)  What are people *actually using* this technology for?
>Flight control? Banking? Scientific computing?  What example
>real projects are there?  Is it for performance? reliability?
>controlling many remote peripherals? real-time?
>Is it generally homo- or heterogenous?

I'd like to have an answer to that one too. I don't think its really usable for
a hard real-time system, as there is no way to guarantee response time. In fact,
its tough to achieve this with any networking software. You pretty much have to
control the transmission method used for everything from the application layer
down to the physical layer.

>I would like to use something like this for programming a
>processor farm of commodity PCs, but this is tricky if the
>bandwidth can't be improved.

For a while I was looking at using it to distribute SETI@Home work units in a
hetrogenious networked environment. However, since work units in the SETI world
are typically manipulated either as files or via http, I eventually concluded
that Annex E wouldn't be the best way to go about it. I'm still looking for a
good use for Annex E...

>is "cool", easy to use and effective... all I need now is an application
>that would benefit significantly from it.

I'm with you.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada Annex E (Just curious :-)

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:FONo6.1740$45.2180@www.newsranger.com...
> I'd like to have an answer to that one too. I don't think its really
usable for
> a hard real-time system, as there is no way to guarantee response time. In
fact,
> its tough to achieve this with any networking software. You pretty much
have to
> control the transmission method used for everything from the application
layer
> down to the physical layer.
>
I would agree that the lack of predictable latency makes it of somewhat
dubious value for realtime systems. It would seem that it might be useful if
you had some form of background workload that you could pass off to another
processor and it didn't matter if the work got done in some predictable
timeframe. (For example, you might have some kind of diagnostics performed
on your realtime data that needed to be done as often as possible, but just
to issue some sort of display info to the operator. An unusual delay might
not be a big deal.)

Or possibly if you had multiple processors in a system that controlled
different hardware? Say, having a graphics processor to which you performed
RPC's to get certain things rendered? (Of course, this would require either
a very standardized processor/communications-interface or you'd never get
the compiler modified to suit the environment. :-)

It would seem that it might be useful for either computationally intensive
applications that lend themselves to distribution (I've seen it done with
CFD calculations) or database systems such as, say, teller machines that
want to verify a bank balance with a central computer before allowing a
withdrawal.

Of course, one could achieve any of these things by other means than having
an RPC. One could pass messages through pipes or TCP/IP sockets or any other
means & establish some kind of protocol between the applications. However,
it seems (all other things being equal - as seldom they are ;-) that an RPC
might be more invisible to the application programmer than other solutions
might be. ("Here you go: Just call this procedure and don't worry about the
rest. We'll handle all the distribution for you...")

> >is "cool", easy to use and effective... all I need now is an application
> >that would benefit significantly from it.
>
> I'm with you.

Maybe its just the application domain you are usually involved in? Remember,
it is a "Special Needs Annex" and may just be the kind of thing that is more
common for a different problem domain. (I'd think it would be used heavily
in business applications where there was at most a soft-realtime
requirement.)

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/

Re: Ada Annex E (Just curious :-)

[Dr Adrian Wrigley]

Marin David Condic wrote:
...
> I would agree that the lack of predictable latency makes it of somewhat
> dubious value for realtime systems.
...

I was thinking about the viability of using Annex E in a system with
multiple microprocessors, sharing only part of their memory space.
Suppose there was a coherent cache or multi-port memory, the
Annex E implementation could work by referring to blocks of memory,
making response times predictable, and performance high.

Ideally, you could create a big data structure in shared memory, and
access it from many partitions at once.  If the memory pattern was
entirely read-only, once created, each partition could locally
cache the shared data, without serious time penalty for maintaining coherency.

> Or possibly if you had multiple processors in a system that controlled
> different hardware? Say, having a graphics processor to which you performed
> RPC's to get certain things rendered? (Of course, this would require either
> a very standardized processor/communications-interface or you'd never get
> the compiler modified to suit the environment. :-)

Funny you should say that... I was thinking of implementing rendering algorithms,
using Annex E over shared memory.  The performance I got from the little demo
(over 100Mbps network, 100kB transfers) was disappointing though.
I think hacking into the parameter marshaling code might sort that out.

> It would seem that it might be useful for either computationally intensive
> applications that lend themselves to distribution (I've seen it done with
> CFD calculations) or database systems such as, say, teller machines that
> want to verify a bank balance with a central computer before allowing a
> withdrawal.

I was thinking of the teller machines example as "controlling many remote
peripherals".  Each machine has its own local screen, keyboard, etc.
and Annex E could be used to put a partition in each machine to control them.
I don't think it would be considered a very practicable system though,
since people want to implement each machine independently, using an
agreed protocol, rather than unifying everything into a single 5000 partition
program.  How do you upgrade systems? Implement redundancy? etc.

> Maybe its just the application domain you are usually involved in? Remember,
> it is a "Special Needs Annex" and may just be the kind of thing that is more
> common for a different problem domain. (I'd think it would be used heavily
> in business applications where there was at most a soft-realtime
> requirement.)

I've been involved in several diverse domains.  Embedded systems with
hard realtime and soft realtime components and many peripherals
seems most plausible use today. Take a mobile 'phone, for example -
that might have hard realtime voiceband (maybe RF) DSP, as well as
keyboard, display, power control etc.  Currently, there would be
a "standard" DSP, and a "standard" microcontroller, but with
separate development groups, and an ad-hoc inter-processor communications
protocol.  Annex E could help here.  In theory.
--
Adrian Wrigley

Re: Ada Annex E (Just curious :-)

[Ted Dennison]

In article <3AA43C58.105B970D@linuxchip.demon.co.uk>, Dr Adrian Wrigley says...
>
>I was thinking about the viability of using Annex E in a system with
>multiple microprocessors, sharing only part of their memory space.
>Suppose there was a coherent cache or multi-port memory, the
>Annex E implementation could work by referring to blocks of memory,
>making response times predictable, and performance high.

Admittedly, I don't know all that much about Annex E. But in this situation, why
wouldn't you prefer to have direct compiler support for putting tasks on
different processors, rather than mess with Annex E? The Harris Nighthawk
(Ada83) compiler worked that way (and was quite nice for hard-realtime). Ada
95's protected types seem tailor-made for this kind of setup. I'd think Annex E
would be more suited to a situation where you have multiple processors that
share *no* memory and must communicate through I/O. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada Annex E (Just curious :-)

[Marin David Condic]

I think the advantage would be this: Each processor with its local memory
could have its own "Main Program". The shared memory could be mapped to a
partition under Annex E and simply accessed as if it was another package.
Hence, most of the complexity is abstracted away. Each processor just looks
like its own app without much low-level concern about the other processors
or shared memory. (Naturally, at a high level, they actually have to behave
as if they know of the existence of each other, or there isn't much point in
having the shared resources, right?)

Obviously, there is more than one way to skin this cat, but having glanced
at the rationale for Annex E, I can see how it was intended to be used and
could be fairly handy for some systems with shared resources. I think that a
big drawback would be that to use it in a system that didn't have a nice,
common architecture & RTK/RTOS, you'd have to get your compiler
custom-modified for the hardware you had. (exempli gratis: you have a
computer with multiple processors of different architectures - DSPs,
Graphics, etc, shared memory of different types, no "standard" OS resident
on each processor's local partition so you don't have POSIX calls or
something similar to rely on, ad nauseum... How would you get a compiler -
or compilers? - that would be able to effectively target all the processors
& shared memory & work invisibly unless you go and custom build it? Better
you use different compilers & establish some kind of communications protocol
between them rather than try to use RPCs or other Annex E mechanisms.)

In situations where the multiple resources have some sort of common
underlying mechanisms - and you can live with whatever
overhead/nondeterminism may be imposed - I could see how the Annex E
direction would be a good choice.

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/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:pP6p6.95$54.78@www.newsranger.com...
> In article <3AA43C58.105B970D@linuxchip.demon.co.uk>, Dr Adrian Wrigley
says...
> >
> >I was thinking about the viability of using Annex E in a system with
> >multiple microprocessors, sharing only part of their memory space.
> >Suppose there was a coherent cache or multi-port memory, the
> >Annex E implementation could work by referring to blocks of memory,
> >making response times predictable, and performance high.
>
> Admittedly, I don't know all that much about Annex E. But in this
situation, why
> wouldn't you prefer to have direct compiler support for putting tasks on
> different processors, rather than mess with Annex E? The Harris Nighthawk
> (Ada83) compiler worked that way (and was quite nice for hard-realtime).
Ada
> 95's protected types seem tailor-made for this kind of setup. I'd think
Annex E
> would be more suited to a situation where you have multiple processors
that
> share *no* memory and must communicate through I/O.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Ada Annex E (Just curious :-)

[Kevin Rigotti]

Marin David Condic wrote in message <982veb$l62$1@nh.pace.co.uk>...
>Obviously, there is more than one way to skin this cat, but having glanced
>at the rationale for Annex E, I can see how it was intended to be used and
>could be fairly handy for some systems with shared resources. I think that
a
>big drawback would be that to use it in a system that didn't have a nice,
>common architecture & RTK/RTOS, you'd have to get your compiler
>custom-modified for the hardware you had.

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

Re: Ada Annex E (Just curious :-)

[Marin David Condic]

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
>
>

Re: Ada Annex E (Just curious :-)

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

>...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.

A major goal of Annex E is to allow the user of a compiler, or a third
party, to provide the (low-level) communications software, *without*
modifying the compiler.  The compiler provides marshalling/unmarshalling
of data structures and so forth, and there's a well-defined interface to
the communications software, so you should be able to plug in your own,
and still get RPC.  Is there some way in which this goal is not
achieved?

- Bob

Re: Ada Annex E (Just curious :-)

[Marin David Condic]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccg0gqqzvc.fsf@world.std.com...
> A major goal of Annex E is to allow the user of a compiler, or a third
> party, to provide the (low-level) communications software, *without*
> modifying the compiler.  The compiler provides marshalling/unmarshalling
> of data structures and so forth, and there's a well-defined interface to
> the communications software, so you should be able to plug in your own,
> and still get RPC.  Is there some way in which this goal is not
> achieved?
>
Well, this is, of course, going to be implementation dependent. I could
imagine a well designed compiler providing a well documented programming
interface so that the embedded developer had to build some
packages/subprograms & link with the compiler's runtime and - "then a
miracle occurs" - and you're off and running with RPC's, etc.

But you've still got potential problems because you may have different
compilers for the different processors. They may not do things quite the
same way, so you aren't necessarily going to be able to get the code from
one compiler to RPC code from the other. The situation with simple data
accesses is similar.

Please, don't get me wrong here. I think the Distributed Annex is a great
idea and goes a long way to providing solutions for a lot of problems. I'm
just observing that in a problem space where you have dissimilar computers
and non-standard communication mechanisms, it may be difficult to use Annex
E. Even something like having to build the communication interface
underneath the compiler is still a matter of mucking about with the compiler
to adapt it to your machine. This doesn't get done at no cost. Maybe you can
get there and maybe it even ends up cheaper in the long run because of
reduced complexity, but it is something that needs to be looked at carefully
depending on the environment.

I recall hearing that in Japan, it is considered rude to say that you can't
do something or that something is impossible - so they say "It would be
difficult" instead. I'm wondering if I'm saying that with the same meaning?
:-)

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/

Re: Ada Annex E (Just curious :-)

[Randy Brukardt]

Marin David Condic wrote in message <985hgg$hqu$1@nh.pace.co.uk>...
>
>
>"Robert A Duff" <bobduff@world.std.com> wrote in message
>news:wccg0gqqzvc.fsf@world.std.com...
>> A major goal of Annex E is to allow the user of a compiler, or a
third
>> party, to provide the (low-level) communications software, *without*
>> modifying the compiler.  The compiler provides
marshalling/unmarshalling
>> of data structures and so forth, and there's a well-defined interface
to
>> the communications software, so you should be able to plug in your
own,
>> and still get RPC.  Is there some way in which this goal is not
>> achieved?
>>
>Well, this is, of course, going to be implementation dependent. I could
>imagine a well designed compiler providing a well documented
programming
>interface so that the embedded developer had to build some
>packages/subprograms & link with the compiler's runtime and - "then a
>miracle occurs" - and you're off and running with RPC's, etc.

No, no, no. Annex E provides a standard package for all of that stuff
(see E.5), the compiler is required to allow the user to change that
package (and the ACATS tests do exactly that).

So it had better be implementation-independent.

>But you've still got potential problems because you may have different
>compilers for the different processors. They may not do things quite
the
>same way, so you aren't necessarily going to be able to get the code
from
>one compiler to RPC code from the other. The situation with simple data
>accesses is similar.


It is true that marshalling and unmarshalling can be a problem. That
usually can be handled with overrides to 'Read and 'Write. (Indeed, that
is a major reason that they can be overridden).

                Randy.

Re: Ada Annex E (Just curious :-)

[Marin David Condic]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:_Mup6.4125$7e6.1607402@homer.alpha.net...
> No, no, no. Annex E provides a standard package for all of that stuff
> (see E.5), the compiler is required to allow the user to change that
> package (and the ACATS tests do exactly that).
>
> So it had better be implementation-independent.
>
O.K. I stand corrected. I'm not as familiar with Annex E as maybe I should
be, it appears. :-)

What you're saying is that you'd do some sort of extension to System.RPC and
fill in the read/write/do_rpc stuff? The dispatching handles the rest? That
would go a long way to making it fairly easy to modify the behavior to get
what you want.

Now your only issue would be efficiency - and of course that's always an
issue that is going to depend on the quality of the compiler in question
anyway. The best you could do is have some benchmark programs & run some
tests...

> It is true that marshalling and unmarshalling can be a problem. That
> usually can be handled with overrides to 'Read and 'Write. (Indeed, that
> is a major reason that they can be overridden).
>
I've had representation issues with the 'Read and 'Write stuff before. I've
also expressed complaints about its efficiency. I suppose if I were molding
all this stuff to a specific environment I might resort to assembly code if
I couldn't get around the Ada rules. It would be ugly, but it might get the
job done.

In general, I've not been 100% happy with the behavior of streams and the
'Read & 'Write stuff. It may be fine for things that are done with the same
compiler/hardware/os at both ends and where speed is not a critical issue.
Where things get heterogeneous and you have performance issues, I think the
requirements for that part of Ada are not very user friendly (at least if
the user is me! :-) One might say "A Solution Does Exist" - but I might
retort "It Would Be Difficult."

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/

Re: Ada Annex E (Just curious :-)

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> What you're saying is that you'd do some sort of extension to System.RPC and
> fill in the read/write/do_rpc stuff? The dispatching handles the rest? That
> would go a long way to making it fairly easy to modify the behavior to get
> what you want.

Package RPC is just an interface -- the package spec defines the
interface between the compiler's generated code and the lower-level
message-passing stuff.  The Ada programmer writes the *body* of this
package.  (The compiler writer can provide one or more bodies, of
course, but it doesn't have to.)

Given that the semantics of this interface are defined in the RM, having
the user write this body does not constitute hacking on the compiler's
internals, as you seemed to think before.

You should read RM-E.5.  Also DR-8652/0087 (that's paragraph
E.5(24.1/1-24.2/1) in the October 2000 version of the AARM -- the one
with DR's inserted).

The other problem you mentioned is non-portability of the
representations supported by 'Read and 'Write; their default behavior is
implementation defined, so in a heterogeneous environment, you will have
to write your own.  I wish we had been more ambitious, and designed more
built-in support for heterogeneous systems.  In this "internet age",
that would be a pretty cool thing.

> In general, I've not been 100% happy with the behavior of streams and the
> 'Read & 'Write stuff.

I must admit: there were many language design mistakes in this area:
look at all the AI's that came out of this section.

- Bob

Re: Ada Annex E (Just curious :-)

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Well, this is, of course, going to be implementation dependent. I could
> imagine a well designed compiler providing a well documented programming
> interface so that the embedded developer had to build some
> packages/subprograms & link with the compiler's runtime and - "then a
> miracle occurs" - and you're off and running with RPC's, etc.

No, as I said in another note, it's not implementation dependent.
The relevant interfaces are defined by the language, not by the
implementation.  If there are mistakes in the interface definition, I'd
like to hear about them.

>...Even something like having to build the communication interface
> underneath the compiler is still a matter of mucking about with the compiler
> to adapt it to your machine. This doesn't get done at no cost.

I would think the cost of writing comm software would be the same,
whether or not you use Annex E.

> I recall hearing that in Japan, it is considered rude to say that you can't
> do something or that something is impossible - so they say "It would be
> difficult" instead. I'm wondering if I'm saying that with the same meaning?
> :-)

Perhaps not as difficult as you imagined.  ;-)

- Bob

Re: Ada Annex E (Just curious :-)

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Admittedly, I don't know all that much about Annex E. But in this situation, why
> wouldn't you prefer to have direct compiler support for putting tasks on
> different processors, rather than mess with Annex E? The Harris Nighthawk
> (Ada83) compiler worked that way (and was quite nice for hard-realtime). Ada
> 95's protected types seem tailor-made for this kind of setup. I'd think Annex E
> would be more suited to a situation where you have multiple processors that
> share *no* memory and must communicate through I/O.

One can argue that Annex E is completely superfluous. One could have a
compiler that targeted a distributed system, and converted all intertask
communications (rendezvous and protected operations) into network
messages. A program for a distributed system could look exactly like a
program for a multiprocessor, which would make porting from one to the
other much simpler.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail

Re: Ada Annex E (Just curious :-)

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> One can argue that Annex E is completely superfluous. One could have a
> compiler that targeted a distributed system, and converted all intertask
> communications (rendezvous and protected operations) into network
> messages. A program for a distributed system could look exactly like a
> program for a multiprocessor, which would make porting from one to the
> other much simpler.

One can argue that, but I don't think it's true.  ;-)
I implemented such a beast for Ada 83.  You could put tasks
on different nodes of a distributed system.  You could control where
they ran, or let the system choose (some sort of primitive load
balancing).  Rendezvous was implemented in terms of message passing
across the network.

But we had to "cheat" a little bit.  Above, you mention "rendezvous and
protected operations" as the intertask communications mechanisms.  But
there's another one: shared variables.  In Ada (83 and 95) it is
perfectly legitimate for two tasks to refer to the same variable (so
long as they synchronize properly, perhaps using rendezvous).  But the
compiler can't tell which variables are shared.  This pretty much
implies that all tasks must share the same address space.  (You *could*
implement distributed shared memory in software, but it would be
intolerably slow.  And you would have to pay that price even for
variables local to a single task (or node), because the compiler can't
tell which variables are shared).

Our solution was to make it the programmer's problem: We allocated each
variable in the address space of the task that elaborated it.  If some
other task in some other node were to refer to that variable, it just
wouldn't work (it would refer to a bogus address, and get junk data or
segmentation fault or whatever).

So you couldn't just take any random Ada program and make it distributed.
You had to design your program carefully to avoid all use of shared
variables.

I don't remember what we did with heap data.

We considered having a pragma that would indicate which variables are
shared.  The obvious name would be "pragma Shared", but Ada 83 already
(annoyingly) defined pragma Shared to mean something different.  Anyway,
we never got around to implementing that.

Another more minor problem had to do with timed and conditional entry
calls.  Which node does the timing?  And what does it mean for an entry
to be "immediately" ready to go, when it takes a non-trivial amount of
time to find out (you have to send a message and receive a reply).
These questions had fairly obvious answers, but again, the programmer
would have to design the program with distribution in mind, because
timing across a distributed system with multiple clocks isn't quite as
simple as in a single shared-memory, single-clock situation.

So I think Annex E is really a better solution to the problem.
You (and the compiler) can control whether there is any shared data,
and if so, which variables.  And there is no timed RPC (although you can
wrap an RPC in a select-then-abort, I suppose).

If I were designing a language from scratch, I think I would have three
kinds of object: constants (which can be shared by copying them to
everywhere they're needed), variables that are local to the task that
elaborated their declaration, and "shared" variables, that can be
referenced by more than one task.  This would require marking procedures
syntactically, if they are called by any "other" task.  In such a
language, I think your idea makes sense: let tasks run in shared memory,
or in a distributed way, depending on what the programmer wants.

- Bob

Re: Ada Annex E (Just curious :-)

[Jeffrey Carter]

Robert A Duff wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> writes:
> 
> > One can argue that Annex E is completely superfluous. One could have a
> > compiler that targeted a distributed system, and converted all intertask
> > communications (rendezvous and protected operations) into network
> > messages. A program for a distributed system could look exactly like a
> > program for a multiprocessor, which would make porting from one to the
> > other much simpler.
> 
> One can argue that, but I don't think it's true.  ;-)
> I implemented such a beast for Ada 83.  You could put tasks
> on different nodes of a distributed system.  You could control where
> they ran, or let the system choose (some sort of primitive load
> balancing).  Rendezvous was implemented in terms of message passing
> across the network.
> 
> But we had to "cheat" a little bit.  Above, you mention "rendezvous and
> protected operations" as the intertask communications mechanisms.  But
> there's another one: shared variables.  In Ada (83 and 95) it is
> perfectly legitimate for two tasks to refer to the same variable (so
> long as they synchronize properly, perhaps using rendezvous).  But the
> compiler can't tell which variables are shared.  This pretty much
> implies that all tasks must share the same address space.  (You *could*
> implement distributed shared memory in software, but it would be
> intolerably slow.  And you would have to pay that price even for
> variables local to a single task (or node), because the compiler can't
> tell which variables are shared).

That's true, but I think disallowing shared variables (except protected
objects) is reasonable for all systems :)

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: Ada Annex E (Just curious :-)

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> Admittedly, I don't know all that much about Annex E. But in this situation, why
> wouldn't you prefer to have direct compiler support for putting tasks on
> different processors, rather than mess with Annex E?

Ada tasking pretty much assumes that "all" memory is shared among all
tasks.  Annex E is designed to support the distributed (no shared
memory) case, and also the mixed case (*some* memory is shared -- see
shared passive packages).

- Bob