* Message passing code @ 1999-06-24 0:00 David Kristola 1999-06-24 0:00 ` ada_daddy 1999-06-24 0:00 ` Dale Stanbrough 0 siblings, 2 replies; 12+ messages in thread From: David Kristola @ 1999-06-24 0:00 UTC (permalink / raw) Over the years i have worked on a number of projects that have implemented various message passing schemes for "unique" hardware. They usually had a number of traits in common (ports and channels). Is there a standard interface for such things, and if so, is there source code that will work without modification (i.e. standard Ada) in a single program, and only need modification in localized places (child packages) to work with specific hardware? Thanks for any help that will keep me from reinventing another wheel. --djk, keeper of arcane lore & trivial fluff Home: David95037 at aol dot com Spam: goto.hades@welovespam.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-24 0:00 Message passing code David Kristola @ 1999-06-24 0:00 ` ada_daddy 1999-06-24 0:00 ` Bruce or Tracy 1999-06-24 0:00 ` Dale Stanbrough 1 sibling, 1 reply; 12+ messages in thread From: ada_daddy @ 1999-06-24 0:00 UTC (permalink / raw) In article <7ksh2u$e1e2@svlss.lmms.lmco.com>, dkristol@see-my.sig wrote: > Over the years i have worked on a number of projects that have > implemented various message passing schemes for "unique" hardware. > They usually had a number of traits in common (ports and channels). > > Is there a standard interface for such things, and if so, is there > source code that will work without modification (i.e. standard Ada) > in a single program, and only need modification in localized > places (child packages) to work with specific hardware? > > Thanks for any help that will keep me from reinventing another wheel. It really depends upon what you mean by message passing systems. If you want to pass messages between Ada tasks, then yes. Ada provides Rendezvous and protected objects for passing messages between tasks. These are all implemented in a hardware independent manner. Jim Rogers Omnitech Robotics, Inc. Englewood, Colorado Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-24 0:00 ` ada_daddy @ 1999-06-24 0:00 ` Bruce or Tracy 1999-06-25 0:00 ` Jim Rogers 0 siblings, 1 reply; 12+ messages in thread From: Bruce or Tracy @ 1999-06-24 0:00 UTC (permalink / raw) At work, we are currently using Ada.Stream. This is the mechanism for (at least parts of) HLA (High Level Architecture) where separate simulations communicate via a Run Time Infrastructure package. In the past, others used IEEE standards' formatted text strings in the DIS world. In these instances, the format of the message as well as the mechanism were a standard for that particular certification. ada_daddy@my-deja.com wrote: > > In article <7ksh2u$e1e2@svlss.lmms.lmco.com>, > dkristol@see-my.sig wrote: > > Over the years i have worked on a number of > projects that have > > implemented various message passing schemes > for "unique" hardware. > > They usually had a number of traits in common > (ports and channels). > > > > Is there a standard interface for such things, > and if so, is there > > source code that will work without modification > (i.e. standard Ada) > > in a single program, and only need modification > in localized > > places (child packages) to work with specific > hardware? > > > > Thanks for any help that will keep me from > reinventing another wheel. > > It really depends upon what you mean by message > passing systems. > If you want to pass messages between Ada tasks, > then yes. > Ada provides Rendezvous and protected objects for > passing > messages between tasks. These are all implemented > in a > hardware independent manner. > > Jim Rogers > Omnitech Robotics, Inc. > Englewood, Colorado > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-24 0:00 ` Bruce or Tracy @ 1999-06-25 0:00 ` Jim Rogers 1999-06-25 0:00 ` Ted Dennison 1999-06-25 0:00 ` Bruce or Tracy 0 siblings, 2 replies; 12+ messages in thread From: Jim Rogers @ 1999-06-25 0:00 UTC (permalink / raw) In article <3772AD75.F5E8AAED@hiwaay.net>, Bruce or Tracy <bljacobs@hiwaay.net> wrote: > At work, we are currently using Ada.Stream. This is > the mechanism for (at least parts of) HLA (High > Level Architecture) where separate simulations > communicate via a Run Time Infrastructure package. > > In the past, others used IEEE standards' formatted > text strings in the DIS world. > > In these instances, the format of the message as > well as the mechanism were a standard for that > particular certification. > Ada.Streams is a very good tool. It is not, however, a standard beyond the world of Ada. Ada.Streams is a tool for converting between a binary data stream and internal Ada object representation. The binary data stream format must still be "standardized", or at least agreed upon by all applications cooperating in a communication community. -- Jim Rogers Colorado Springs, Colorado USA Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-25 0:00 ` Jim Rogers @ 1999-06-25 0:00 ` Ted Dennison 1999-06-28 0:00 ` Robert Dewar 1999-06-25 0:00 ` Bruce or Tracy 1 sibling, 1 reply; 12+ messages in thread From: Ted Dennison @ 1999-06-25 0:00 UTC (permalink / raw) In article <7l0gj5$b62$1@nnrp1.deja.com>, Jim Rogers <ada_daddy@my-deja.com> wrote: > In article <3772AD75.F5E8AAED@hiwaay.net>, > Bruce or Tracy <bljacobs@hiwaay.net> wrote: > > At work, we are currently using Ada.Stream. This is > > the mechanism for (at least parts of) HLA (High > > Level Architecture) where separate simulations > > communicate via a Run Time Infrastructure package. > > Ada.Streams is a very good tool. It is not, however, a standard > beyond the world of Ada. Ada.Streams is a tool for converting > between a binary data stream and internal Ada object representation. > The binary data stream format must still be "standardized", or > at least agreed upon by all applications cooperating in a > communication community. That's true. In fact, I don't think it is even guaranteed to work between different platforms or compilers. You don't know what Ada.Streams.Stream_Element is, or how big it is. Unless you write it yourself, you don't know how your stream is implemented or how data gets placed in it. Encryption or compression could be going on, for all you know. Unless you write them yourself, you don't know how 'Read and 'Write are converting between your objects and stream elements. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-25 0:00 ` Ted Dennison @ 1999-06-28 0:00 ` Robert Dewar 1999-06-28 0:00 ` Jim Rogers 0 siblings, 1 reply; 12+ messages in thread From: Robert Dewar @ 1999-06-28 0:00 UTC (permalink / raw) In article <7l0s5k$g32$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > Unless you write them yourself, you don't know how 'Read and > 'Write are converting between your objects and stream > elements. I certainly HOPE this is false with any reasonable Ada 95 compiler. It should be quite transparent what the conversion mechanism is. In the case of GNAT, you can look at s-stratt.adb which encapsulates the conversions used (we have two versions that are standard, and easy to read and understand, one for native format, and one which uses XDR for platform independence). You can if you like write your own version of s-stratt.adb to control the underlying default translations that are used. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-28 0:00 ` Robert Dewar @ 1999-06-28 0:00 ` Jim Rogers 0 siblings, 0 replies; 12+ messages in thread From: Jim Rogers @ 1999-06-28 0:00 UTC (permalink / raw) In article <7l6lni$4a5$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: > In article <7l0s5k$g32$1@nnrp1.deja.com>, > Ted Dennison <dennison@telepath.com> wrote: > > > Unless you write them yourself, you don't know how 'Read and > > 'Write are converting between your objects and stream > > elements. > > I certainly HOPE this is false with any reasonable Ada 95 > compiler. It should be quite transparent what the conversion > mechanism is. In the case of GNAT, you can look at s-stratt.adb > which encapsulates the conversions used (we have two versions > that are standard, and easy to read and understand, one for > native format, and one which uses XDR for platform > independence). You can if you like write your own version of > s-stratt.adb to control the underlying default translations > that are used. Unfortunately, I have had some nasty surprises in this area from ObjectAda. Example: type Byte is mod 2**8; for Byte'Size use 8; I assumed that the native stream representation of the above type would be represented in 8 bits. In fact it is represented on the stream in 32 bits. The only way I could assure that this type would occupy only 8 bits in my stream was to write customized 'Read and 'Write procedures. Aonix calls this a feature. They use the Intermetrics front end. Apparently this is the behavior preferred by Tucker Taft, who insists that the stream should represent all values by the size of the Base type, and the Base type for all integer types is Universal Integer. This is my understanding of the Aonix rationale. I am sure I will be corrected if I am wrong. -- Jim Rogers Colorado Springs, Colorado USA Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-25 0:00 ` Jim Rogers 1999-06-25 0:00 ` Ted Dennison @ 1999-06-25 0:00 ` Bruce or Tracy 1 sibling, 0 replies; 12+ messages in thread From: Bruce or Tracy @ 1999-06-25 0:00 UTC (permalink / raw) Right, Ada.Streams is not the standard - the standard was the IEEE DIS interface. Ada.Streams, now that we are using Ada95 (finally!), is the agreed upon communication interface mechanism between us and our RTI. How RTI communications with the rest of the world is decided, as I understand it, between RTI and the rest of the world. Ada.Streams is not a stardard by any means. I don't think I said that, but it maybe could have been implied. In fact, the RTI itself is in C++. They have to do a conversion from our RTI/Ada95 interface mechanism to whatever their C++ requires - I think it uses a base-type of string. Ada.Streams, as I understand the politics of the situation, is a hand-shake agreement under the table. However, our agreement was to follow their lead in using Ada.Streams. The more I use streams, the more I like them. The 'WRITE and 'READ attributes are very nice - keeps one from having to count bytes. Being Ada95 controlled, insertion and extraction errors are *almost* eliminated. Bruce Jim Rogers wrote: > > In article <3772AD75.F5E8AAED@hiwaay.net>, > Bruce or Tracy <bljacobs@hiwaay.net> wrote: > > At work, we are currently using Ada.Stream. This is > > the mechanism for (at least parts of) HLA (High > > Level Architecture) where separate simulations > > communicate via a Run Time Infrastructure package. > > > > In the past, others used IEEE standards' formatted > > text strings in the DIS world. > > > > In these instances, the format of the message as > > well as the mechanism were a standard for that > > particular certification. > > > > Ada.Streams is a very good tool. It is not, however, a standard > beyond the world of Ada. Ada.Streams is a tool for converting > between a binary data stream and internal Ada object representation. > The binary data stream format must still be "standardized", or > at least agreed upon by all applications cooperating in a > communication community. > > -- > Jim Rogers > Colorado Springs, Colorado USA > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-24 0:00 Message passing code David Kristola 1999-06-24 0:00 ` ada_daddy @ 1999-06-24 0:00 ` Dale Stanbrough 1999-06-25 0:00 ` David Kristola 1 sibling, 1 reply; 12+ messages in thread From: Dale Stanbrough @ 1999-06-24 0:00 UTC (permalink / raw) dkristol@see-my.sig wrote: " Over the years i have worked on a number of projects that have implemented various message passing schemes for "unique" hardware. They usually had a number of traits in common (ports and channels). Is there a standard interface for such things, and if so, is there source code that will work without modification (i.e. standard Ada) in a single program, and only need modification in localized places (child packages) to work with specific hardware?" Glade (the ACT implementation of the Ada distributed systems annex) and MPI (message passing interface). I don't know of any Ada bindings, but i would guess it is pretty trivial from what i have seen. (I wonder if the two could be combined...) Dale ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-24 0:00 ` Dale Stanbrough @ 1999-06-25 0:00 ` David Kristola 1999-06-25 0:00 ` tmoran 0 siblings, 1 reply; 12+ messages in thread From: David Kristola @ 1999-06-25 0:00 UTC (permalink / raw) In article 2406991635080001@dale.cs.rmit.edu.au, dale@cs.rmit.edu.au (Dale Stanbrough) writes: >dkristol@see-my.sig wrote: > >" Over the years i have worked on a number of projects that have > implemented various message passing schemes for "unique" hardware. > They usually had a number of traits in common (ports and channels). > > Is there a standard interface for such things, and if so, is there > source code that will work without modification (i.e. standard Ada) > in a single program, and only need modification in localized > places (child packages) to work with specific hardware?" > > >Glade (the ACT implementation of the Ada distributed systems annex) This does not fit the bill. I am trying to pass messages, not do remote procedure calls, and besides, the compiler has no clue how the hardware is connected. I get the pleasure of writing that. By the time i expand on the basic streams concept, well, i am back to where i started: doing it all myself. Once i have a basic message passing system set up, it would be easy to make a stream interface for it. But what should that interface look like? package Ada.Streams.Messages is type Stream_Access is access all Root_Stream_Type'Class; type Channel_Type is ... type Port_Type is limited private; procedure Open (Port : in out Port_Type; Channel : in Channel_Type); function Stream(Port : in Port_Type) return Stream_Access; -- etc. end Ada.Streams.Messages; I can see this causing problems, especially when someone creates their Write routines to break up large objects into lots of small, discrete objects. The data would probably need to be wrapped at a lower level, and sent over as packets. This would cause some large objects to be sent as many small packets, and this could be terrible, depending on the hardware moving the data. >MPI (message passing interface). I don't know of any Ada bindings, but >i would guess it is pretty trivial from what i have seen. This is pretty close to what i am looking for, but i haven't found an Ada implementation (a binding would not work because they don't make what i would need to bind to for the hardware in question). --djk, keeper of arcane lore & trivial fluff Home: David95037 at aol dot com Spam: goto.hades@welovespam.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-25 0:00 ` David Kristola @ 1999-06-25 0:00 ` tmoran 1999-06-25 0:00 ` David Kristola 0 siblings, 1 reply; 12+ messages in thread From: tmoran @ 1999-06-25 0:00 UTC (permalink / raw) >I can see this causing problems, especially when someone creates their >Write routines to break up large objects into lots of small, discrete >objects. The data would probably need to be wrapped at a lower level, >and sent over as packets. This would cause some large objects to be >sent as many small packets, and this could be terrible, depending on I'm not clear on what you want, but if small packets from the many small 'Writes worry you, buffer them up. For writing one or more records as a single object to the clipboard, or writing it as a single datagram write, I use a data marshalling package which includes: -- Writes to a buffer will allocate additional memory from the -- heap as needed. If you know reasonably accurately how much -- you'll need, it will be more efficient to make the -- Initial_Length big enough and thus avoid heap allocation. -- -- Any heap allocation will be freed automatically when a Buffer -- ceases to exist. type Buffer_Type(Initial_Length : Ada.Streams.Stream_Element_Count) is new Ada.Streams.Root_Stream_Type with private; procedure Write(Stream : in out Buffer_Type; Item : in Ada.Streams.Stream_Element_Array); etc. Does that address (part of) the problem? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Message passing code 1999-06-25 0:00 ` tmoran @ 1999-06-25 0:00 ` David Kristola 0 siblings, 0 replies; 12+ messages in thread From: David Kristola @ 1999-06-25 0:00 UTC (permalink / raw) In article 123270@typhoon-sf.snfc21.pbi.net, tmoran@bix.com () writes: >>I can see this causing problems, especially when someone creates their >>Write routines to break up large objects into lots of small, discrete >>objects. The data would probably need to be wrapped at a lower level, >>and sent over as packets. This would cause some large objects to be >>sent as many small packets, and this could be terrible, depending on > I'm not clear on what you want, but if small packets from the many >small 'Writes worry you, buffer them up. For writing one or more records >as a single object to the clipboard, or writing it as a single >datagram write, I use a data marshalling package which includes: > -- Writes to a buffer will allocate additional memory from the > -- heap as needed. If you know reasonably accurately how much > -- you'll need, it will be more efficient to make the > -- Initial_Length big enough and thus avoid heap allocation. > -- > -- Any heap allocation will be freed automatically when a Buffer > -- ceases to exist. > > type Buffer_Type(Initial_Length : Ada.Streams.Stream_Element_Count) > is new Ada.Streams.Root_Stream_Type with private; > > procedure Write(Stream : in out Buffer_Type; > Item : in Ada.Streams.Stream_Element_Array); >etc. >Does that address (part of) the problem? Not really. How does the lower level know when the writing to the stream is done, and it should send the buffer? I guess there could be an explicit Flush command. But now i am doing all kinds of things that don't look like streams any more, so what is the point of trying to look like streams? I don't think streams are the right paradigm for this. When i have a message to send, i want to send the whole thing. That message will have many different things inside of it, and may be different lengths. I would also have to code a Write routine for each message type. That could get ugly. I would rather stick to the old technique of converting it to an array of bytes, and passing those into a Send routine. -- Completely bogus type for example. type Message_Type is record Message_ID : Base_Types.Unsigned_Integer_16_Type := Update_Contact_Table; Concat_ID : Contact_Types.Concat_ID_Type; Location : General_Types.Ownship_Relative_Position_Type; Condition : Something_Else.Some_Interesting_Type; Detection : Sonar.Detection_Method_Type; Checksum : Base_Types.Unsigned_Integer_16_Type; end record; Sonar_Update_Message : Message_Type; Sonar_Update_Message.Checksum := Message_Services.Calculate_Checksum(Convert(Sonar_Update_Message)); MPI.Send(Tactical_Channel, Convert(Sonar_Update_Message)); --djk, keeper of arcane lore & trivial fluff Home: David95037 at aol dot com Spam: goto.hades@welovespam.com ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1999-06-28 0:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-24 0:00 Message passing code David Kristola 1999-06-24 0:00 ` ada_daddy 1999-06-24 0:00 ` Bruce or Tracy 1999-06-25 0:00 ` Jim Rogers 1999-06-25 0:00 ` Ted Dennison 1999-06-28 0:00 ` Robert Dewar 1999-06-28 0:00 ` Jim Rogers 1999-06-25 0:00 ` Bruce or Tracy 1999-06-24 0:00 ` Dale Stanbrough 1999-06-25 0:00 ` David Kristola 1999-06-25 0:00 ` tmoran 1999-06-25 0:00 ` David Kristola
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox