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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Thread: 101deb,15c6ed4b761968e6 X-Google-Attributes: gid103376,gid1094ba,gid101deb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 25 May 2006 11:25:35 -0500 Message-ID: <4475DA0F.5030603@comcast.net> Date: Thu, 25 May 2006 12:23:43 -0400 From: Bob Lidral User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 Subject: Checking for Undefined [was Re: Ada vs Fortran for scientific applications] References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <2006052509454116807-gsande@worldnetattnet> In-Reply-To: <2006052509454116807-gsande@worldnetattnet> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.63.32.141 X-Trace: sv3-j9cY9u9lT0Fn3xd4/Er5e3xhwOf1MaQTyq9CseYISeeK0MDDLeK+fEDOn2huPnh95quFFvV5ujHi7yy!9oAsUvN0xfPY7ZdKox1BEHBwKezuXhOecwq0aV3HntjCwGi40TFz6jivqDFxHbLu X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:4463 comp.lang.fortran:10247 comp.lang.pl1:1708 Date: 2006-05-25T12:23:43-04:00 List-Id: Gordon Sande wrote: > [...] > How many Ada systems can match the undefined variable checking of the > old WatFor or the current Salford CheckMate or the Lahey/Fujitsu > global checking? It seems to be a thing associated with places that > run student cafteria computing on mainframes. Not much used anymore. > There was a similar student checkout PL/I from Cornell if I recall > correctly. > That's one of the features I miss about the old CDC CYBER architectures. Their (one's complement, sigh) numeric format supported plus or minus infinity (e.g., divide a non-zero number by zero) and plus or minus indefinite (e.g., divide zero by zero, infinity by infinity, or use an "indefinite" value anywhere in a divide operation). IIRC (it has been a long time) these values were represented by specific bit patterns in just the sign and exponent fields. (It also helped that the CYBER floating point exponent bias was such that the exponent field was zero for integer values so that integer values representable by 48 or fewer bits were represented by the same bit patterns in either floating point or fixed point. Originally, CYBERs only had an 18-bit address space which was extended in later models to 21 bits and maybe even to 24 bits in still later models. The operating system required the high-order bit of any of those address fields to be zero for user programs. There was an option for the loader that allowed the exploitation of these hardware design features to provide automatic checking for uninitialized values at run time with no run time overhead. The loader provided a way to specify values to be placed into memory for any uninitialized program data (I don't remember whether the default was no value -- e.g., use previous process's leftovers -- or zero). The best patterns to choose for such initial values were {plus | minus} {infinity | indefinite} ORed with a word with bits 17, 20, and 23 set ORed with the load address of the word Unless one enabled the use of infinity and indefinite values for arithmetic processing (I never saw that done, but I'm sure some customer somewhere used it), any use of such values in an arithmetic operation would be detected by the hardware and stop the program with an error message containing the value(s) that caused the problem. Further, any attempt to use such a value as an address would cause the hardware to stop the program with an error because the high-order bit of the address field would be set. Although it didn't provide direct trace back to the source code (because it was strictly a hardware feature), it was possible to do such trace backs using load maps because each word contained the address at which it was originally loaded. Useful, because no such checking was done for assignments. So, if A were uninitialized in the source code, a sequence such as: B = A C = B D = C / 4 would halt the program at the divide operation and print out the values, one of which would contain the address at which A was loaded into memory. All overhead occurred at initial program load time. One obvious limitation was that it only worked well for static data and wasn't all that much help for values allocated on the stack or for values in FORTRAN blank COMMON or the equivalents in other languages. I cringe every time I hear some recent grad new hire insist earnestly that there's no need to initialize anything to zero because that's always done automatically. And they believe that's true for all languages -- even for variables allocated on the stack or heap. Worse, that is in the definitions of a few languages, thus re-inforcing their belief that it's true for all languages. Bob Lidral lidral at alum dot mit dot edu