Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!uvaarpa!mcnc!decvax!decwrl!hplabs!hpda!hpcupt1!hpcuhb!hpcllla!hpclisp!hpclscu!shankar From: shankar@hpclscu.HP.COM (Shankar Unni) Newsgroups: comp.lang.pascal Subject: Re: Global variables Message-ID: <950008@hpclscu.HP.COM> Date: 29 Mar 88 17:42:56 GMT References: Organization: HP ITG/ISD Computer Language Lab Lines: 33 / hpclscu:comp.lang.pascal / dat18@mystefix.liu.se (Dat18) / 5:30 pm Mar 26, 1988 / > Well, everybody knows that massive use of global variables > leads to slower code. > That should settle it! Gee, that's rather a blanket statement, isn't it? Most implementations *I* know of handle local and global references very nicely. It's references that are both non-local and not global (i.e. a level-n routine accessing variables at level m where 1 < m < n) that cause the worst code. Also, (in response to an earlier note), it *is* true that dereferencing a general pointer could access anything. But ideally, true Pascal pointers should only point to the HEAP, which is entirely distinct from locals or globals or any other address space. Of course, if your implementation allows c-style pointers (which can point to any item, stack or heap), then of course, a dereference of such a pointer could write to ANYTHING, INCLUDING YOUR LOCAL VARIABLES!! Goodbye, optimization! Thus, knowing the set of items that a pointer can point to can dramatically improve optimization. It is also helpful if the optimizer can be given hints about such things, though pseudo-comments or such like. About the religious argument about global variables: I believe that globals have their place. They are ugly necessities, not to be indulged in unless the need is truly present. Their misuse can lead to horrible, unmaintainable code. Think of the nightmare of keeping track of side-effects! However, I would not give a second look to a language which did not have adequate facilities for declaration of globals and maintaining them in a separate compilation environment (like that *other* language (NO, NO, NOT FORTRAN!!!!)), because such a language implementation would be TRULY USELESS. --scu