Re: Ada Annex E (Just curious :-)

["Randy Brukardt" <randy@rrsoftware.com>]

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.