From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 21 Sep 92 11:49:04 GMT From: cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!wellerd@ucbvax.Berke ley.EDU (David Weller) Subject: Re: Using Global Variables Message-ID: <1992Sep21.114904.23435@sei.cmu.edu> List-Id: In article <15452@suns5.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) writ es: >[general comments about the sins of globals] >In a flight simulator, nothing is actually encapsulated. Although >one might like to model the aircraft aerodynamics as a closed task >which only replys to requests for, say "current aircraft latitude" >the actual requirement is quite different. Not only must those >requests be satisfied, but quite a lot of what _should_ be internal, >local data must also be exported. I'm talking about last times >values, intermediate values etc. This is to service the >"record/replay" system. Here, the simulator is required to replay >the last few mins of a flight and then the pilot takes over and >tries again. The number of things that have to be stored is >huge. Making the computer hardware architecure fit a nice _closed_ >software model would be amazingly expensive. So it's not done. > >The tried and trusted way to do this in the industry is to share >memory by high speed DMA systems. In FORTRAN systems, these >shared memory areas are overlayed with COMMON blocks. In Ada, >I used address clauses to point at data in those areas. The memory >is global; the data is global and is accessed (read by) many systems; >only a very few systems actually write to specific data items. > >It does require a lot of planning to manage that global data. On >large simulators it has become a full time job just to adapt a >standard "database" to the new simulated system. > >Most people in simulation would like to get away from this >way of doing things (well, actually those who have made a >career out of managing the data are quite happy, but then >they would be!). Unfortunately, the hardware just ain't >good enough yet. (It may never be, as the hardware improves >the requirements of the simulator increase too!) > Boy, hearing comments like this tells me that we must be WAY out on the cutting edge of technology! OK, here's a few myths that I'd also like to hose about flight simulators: 1) You can't encapsulate the date (i.e., OO concepts go to hell in sims). Nothing can be further from the truth. True that this was once considered the norm, but no longer. The C-17 sim is an outstanding example of correctly encapsulating data according to the "real-world". 2) The number of "local data" items to be exported (for record/ play, Instructor manipulation, etc.) is too large to permit encapsulation anyway. El Toro de Poopoo. This is a misconception that frequently drives sim companies to choosing archaic architectures. 3) To have a simulator, you must have a huge, standard database to keep track of the data pool. *Sigh* Yeah, that's how it WAS being done for the Shuttle sim. Talk about a gaggle. The funny thing was that the engineers ACCEPTED that as "normal". Makes shivers run down my spine. This is not a flame, Paul. I wanted to "world" to know that you don't have to give up things like encapsulation and sound engineering concepts to have an efficient real-time, DISTRIBUTED, simulation. We are doing it here in Houston, and it works very nicely, thank you. We intend to publish the datails of our accomplishment next year. Stay tuned for more details. -----No, as a matter of fact, I'm not speaking for my company!--------------- David Weller, | Space Station Training Facility: Like the real CAE-Link, | thing, only you can step outside for a breath Space Technology Div. | of fresh air! ----I'm the Ultimate International Masochist: I speak Ada AND Esperanto!-----