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,6403691d6db186c8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-28 04:09:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!peernews-us.colt.net!newsfeed.news2me.com!newsfeed2.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Getting a symbol table from Gnat 3.15p on Windows Date: Fri, 28 Feb 2003 07:08:14 -0500 Organization: MindSpring Enterprises Message-ID: References: NNTP-Posting-Host: d1.56.b5.0e X-Server-Date: 28 Feb 2003 12:09:20 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:34715 Date: 2003-02-28T12:09:20+00:00 List-Id: We did this with a small part of the system once. We extracted out a realtime model and had special packages that collected up references to the various parameters of interest. It worked, but it wasn't pretty. Every time the realtime model changed we were in there editing those packages to add/delete variables and recompiling the whole mess. It was effective and given the limited scope, not so painful that it stopped us from using it. Here I don't think that would work. The number of variables gets so high and can be so dynamic that it would likely be way too difficult to deal with at that level. Just about the time you got the code rebuilt, someone would issue a new release and you're back to ground zero. Besides, it would not work within the context of the existing toolset and test cases. The idea here was a minimal impact sort of thing - a kind of extension to something they already had. You start changing the concepts too much and the scope of the project has to get too big to sell. An alternative I may have to look at is to see what sort of interfaces I've got at the lowest level and, since I've got to dummy-up the A/D reads, etc anyway, there may be some way of making that accept I/O from a different source with less impact to the system. Of course, this totally blows away my existing internal and external monitor software and test cases, but if I were to go that route, there may be other benefits that make it worth coming up with a new environment. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ====================================================================== wrote in message news:Kns7a.286366$be.259256@rwcrnsc53... > > Its pretty much as you describe. We've got various packages that contain > > global data. The embedded, on-board monitor can read and write any addresses > Given > package One is > Global_Voltage : Integer; > ... > end One; > package Two is > Global_Red_Button_Pushed : Boolean; > ... > end Two; > ... > How about adding > package Self_Description is > begin -- run once at package Self_Description's elaboration time > Tell_Monitor("One.Global_Voltage", One.Global_Voltage'address); > Tell_Monitor("Two.Global_Red_Button_Pushed", > Two.Global_Red_Button_Pushed'address); > ... > end Self_Description; > Assuming of course that 'address in the testee program is meaningful > to the monitor program.