* Re: Ada Annex E (Just curious :-) [not found] <yJSm6.8482$X_2.140961@news1.oke.nextra.no> @ 2001-02-28 13:28 ` Marc A. Criley 2001-03-01 17:33 ` Frank 2001-03-02 9:38 ` Pascal Obry 1 sibling, 1 reply; 23+ messages in thread From: Marc A. Criley @ 2001-02-28 13:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-02-28 13:28 ` Ada Annex E (Just curious :-) Marc A. Criley @ 2001-03-01 17:33 ` Frank 2001-03-02 17:42 ` Robert Spooner 0 siblings, 1 reply; 23+ messages in thread From: Frank @ 2001-03-01 17:33 UTC (permalink / raw) 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. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-01 17:33 ` Frank @ 2001-03-02 17:42 ` Robert Spooner [not found] ` <x7vu25bcl22.fsf@smaug.pushface.org> 0 siblings, 1 reply; 23+ messages in thread From: Robert Spooner @ 2001-03-02 17:42 UTC (permalink / raw) To: Frank 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <x7vu25bcl22.fsf@smaug.pushface.org>]
* Re: Ada Annex E (Just curious :-) [not found] ` <x7vu25bcl22.fsf@smaug.pushface.org> @ 2001-03-05 19:26 ` Robert Spooner 0 siblings, 0 replies; 23+ messages in thread From: Robert Spooner @ 2001-03-05 19:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) [not found] <yJSm6.8482$X_2.140961@news1.oke.nextra.no> 2001-02-28 13:28 ` Ada Annex E (Just curious :-) Marc A. Criley @ 2001-03-02 9:38 ` Pascal Obry 2001-03-04 19:12 ` Dr Adrian Wrigley 1 sibling, 1 reply; 23+ messages in thread From: Pascal Obry @ 2001-03-02 9:38 UTC (permalink / raw) "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" ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-02 9:38 ` Pascal Obry @ 2001-03-04 19:12 ` Dr Adrian Wrigley 2001-03-05 14:56 ` Ted Dennison 0 siblings, 1 reply; 23+ messages in thread From: Dr Adrian Wrigley @ 2001-03-04 19:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-04 19:12 ` Dr Adrian Wrigley @ 2001-03-05 14:56 ` Ted Dennison 2001-03-05 16:24 ` Marin David Condic 0 siblings, 1 reply; 23+ messages in thread From: Ted Dennison @ 2001-03-05 14:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-05 14:56 ` Ted Dennison @ 2001-03-05 16:24 ` Marin David Condic 2001-03-06 1:24 ` Dr Adrian Wrigley 0 siblings, 1 reply; 23+ messages in thread From: Marin David Condic @ 2001-03-05 16:24 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-05 16:24 ` Marin David Condic @ 2001-03-06 1:24 ` Dr Adrian Wrigley 2001-03-06 14:51 ` Ted Dennison 0 siblings, 1 reply; 23+ messages in thread From: Dr Adrian Wrigley @ 2001-03-06 1:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 1:24 ` Dr Adrian Wrigley @ 2001-03-06 14:51 ` Ted Dennison 2001-03-06 15:23 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Ted Dennison @ 2001-03-06 14:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 14:51 ` Ted Dennison @ 2001-03-06 15:23 ` Marin David Condic 2001-03-06 18:42 ` Kevin Rigotti 2001-03-07 6:54 ` Jeffrey Carter 2001-03-07 21:47 ` Robert A Duff 2 siblings, 1 reply; 23+ messages in thread From: Marin David Condic @ 2001-03-06 15:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 15:23 ` Marin David Condic @ 2001-03-06 18:42 ` Kevin Rigotti 2001-03-06 20:56 ` Marin David Condic 0 siblings, 1 reply; 23+ messages in thread From: Kevin Rigotti @ 2001-03-06 18:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 18:42 ` Kevin Rigotti @ 2001-03-06 20:56 ` Marin David Condic 2001-03-06 22:47 ` Robert A Duff 0 siblings, 1 reply; 23+ messages in thread From: Marin David Condic @ 2001-03-06 20:56 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 20:56 ` Marin David Condic @ 2001-03-06 22:47 ` Robert A Duff 2001-03-07 14:43 ` Marin David Condic 0 siblings, 1 reply; 23+ messages in thread From: Robert A Duff @ 2001-03-06 22:47 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 22:47 ` Robert A Duff @ 2001-03-07 14:43 ` Marin David Condic 2001-03-07 18:02 ` Randy Brukardt 2001-03-07 21:45 ` Robert A Duff 0 siblings, 2 replies; 23+ messages in thread From: Marin David Condic @ 2001-03-07 14:43 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-07 14:43 ` Marin David Condic @ 2001-03-07 18:02 ` Randy Brukardt 2001-03-07 19:52 ` Marin David Condic 2001-03-07 21:45 ` Robert A Duff 1 sibling, 1 reply; 23+ messages in thread From: Randy Brukardt @ 2001-03-07 18:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-07 18:02 ` Randy Brukardt @ 2001-03-07 19:52 ` Marin David Condic 2001-03-07 21:04 ` Robert A Duff 0 siblings, 1 reply; 23+ messages in thread From: Marin David Condic @ 2001-03-07 19:52 UTC (permalink / raw) "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/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-07 19:52 ` Marin David Condic @ 2001-03-07 21:04 ` Robert A Duff 0 siblings, 0 replies; 23+ messages in thread From: Robert A Duff @ 2001-03-07 21:04 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-07 14:43 ` Marin David Condic 2001-03-07 18:02 ` Randy Brukardt @ 2001-03-07 21:45 ` Robert A Duff 1 sibling, 0 replies; 23+ messages in thread From: Robert A Duff @ 2001-03-07 21:45 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 14:51 ` Ted Dennison 2001-03-06 15:23 ` Marin David Condic @ 2001-03-07 6:54 ` Jeffrey Carter 2001-03-07 21:39 ` Robert A Duff 2001-03-07 21:47 ` Robert A Duff 2 siblings, 1 reply; 23+ messages in thread From: Jeffrey Carter @ 2001-03-07 6:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-07 6:54 ` Jeffrey Carter @ 2001-03-07 21:39 ` Robert A Duff 2001-03-08 5:53 ` Jeffrey Carter 0 siblings, 1 reply; 23+ messages in thread From: Robert A Duff @ 2001-03-07 21:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-07 21:39 ` Robert A Duff @ 2001-03-08 5:53 ` Jeffrey Carter 0 siblings, 0 replies; 23+ messages in thread From: Jeffrey Carter @ 2001-03-08 5:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Ada Annex E (Just curious :-) 2001-03-06 14:51 ` Ted Dennison 2001-03-06 15:23 ` Marin David Condic 2001-03-07 6:54 ` Jeffrey Carter @ 2001-03-07 21:47 ` Robert A Duff 2 siblings, 0 replies; 23+ messages in thread From: Robert A Duff @ 2001-03-07 21:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2001-03-08 5:53 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <yJSm6.8482$X_2.140961@news1.oke.nextra.no> 2001-02-28 13:28 ` Ada Annex E (Just curious :-) Marc A. Criley 2001-03-01 17:33 ` Frank 2001-03-02 17:42 ` Robert Spooner [not found] ` <x7vu25bcl22.fsf@smaug.pushface.org> 2001-03-05 19:26 ` Robert Spooner 2001-03-02 9:38 ` Pascal Obry 2001-03-04 19:12 ` Dr Adrian Wrigley 2001-03-05 14:56 ` Ted Dennison 2001-03-05 16:24 ` Marin David Condic 2001-03-06 1:24 ` Dr Adrian Wrigley 2001-03-06 14:51 ` Ted Dennison 2001-03-06 15:23 ` Marin David Condic 2001-03-06 18:42 ` Kevin Rigotti 2001-03-06 20:56 ` Marin David Condic 2001-03-06 22:47 ` Robert A Duff 2001-03-07 14:43 ` Marin David Condic 2001-03-07 18:02 ` Randy Brukardt 2001-03-07 19:52 ` Marin David Condic 2001-03-07 21:04 ` Robert A Duff 2001-03-07 21:45 ` Robert A Duff 2001-03-07 6:54 ` Jeffrey Carter 2001-03-07 21:39 ` Robert A Duff 2001-03-08 5:53 ` Jeffrey Carter 2001-03-07 21:47 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox