From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd0ee7c9be011576 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-06 07:36:24 PST Path: supernews.google.com!sn-xit-02!supernews.com!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada Annex E (Just curious :-) Date: Tue, 6 Mar 2001 10:23:16 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <982veb$l62$1@nh.pace.co.uk> References: <3AA29386.E60A686D@linuxchip.demon.co.uk> <980ekl$p4h$1@nh.pace.co.uk> <3AA43C58.105B970D@linuxchip.demon.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 983892235 21698 136.170.200.133 (6 Mar 2001 15:23:55 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 6 Mar 2001 15:23:55 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: supernews.google.com comp.lang.ada:5469 Date: 2001-03-06T15:23:55+00:00 List-Id: 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" 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