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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 21 Sep 92 08:10:26 GMT From: mcsun!uknet!stl!crosfield!pdg@uunet.uu.net (paul goffin) Subject: Re: Using Global Variables Message-ID: <15452@suns5.crosfield.co.uk> List-Id: In article <16864C1E7.M19481@mwvm.mitre.org> M19481@mwvm.mitre.org writes: >In article <1992Sep16.152620.9286@nosc.mil> >sampson@nosc.mil (Charles H. Sampson) writes: #>In article <15390@suns5.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) #>writes (in an article on Ada compiler pricing): #>>new way of managing "global variables" - Yes, nasty as they are, #>>you do sometimes have to use global variables in the real world!) #>>there was a nasty shock in the price of the compilers. #> I'd like to hear more about this need to use global variables in #>the real world, from Mr. Goffin and anyone else. I can't remember the #>last time I used one in an Ada project, and I think what I do is pretty #>real world stuff. (Well, I do contract to the U. S. Navy, but that's #>close.) #The main reason I've heard used to justify the use of global variables is #performance of a real-time system. The argument goes that the overhead of Yes, that's part of it. I worked in flight simulation. As well as the (perceived) need to avoid paramter passing delays, (actually we measured those, they're not as bad as folklore would have one believe) the big need is to share large amounts of data at high speed between multiple computer systems. 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!) Paul -- +-------------+-------------------------------------------------------+ + Paul Goffin + Crosfield Electronics Ltd. U.K. +44 442 230000x3357 + + + Opinions expressed are mine! (Yours for a small fee) + +-------------+-------------------------------------------------------+