Re: Checking for Undefined [was Re: Ada vs Fortran for scientific applications]

[Gordon Sande <g.sande@worldnet.att.net>]

On 2006-05-25 13:23:43 -0300, Bob Lidral <l1dralspamba1t@comcast.net> said:

> 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

The original WatFor for IBM/7040 used a hardware hack. They set bad parity
but since they were a load and go system they had a symbol table around
and did the lookup for you. When WatFor moved to IBM/360 the feature was so
popular that they had to work hard to reproduce the feature.

The Salford folks come form the same cafeteria for student debugging
environment and did the same feature. They even do it for automatic
storeage. They even set INTENT ( IN ) variables to undefined so a
user can set the undefined attribute/(bit configuration) themselves
if they are doing an internal storeage allocation themselves. Neat!

NAG and Lahey/Fujitsu also have the capability but are missing the
setting of automatics if I have the features scoped out correctly.

Initialization to signaling NANs if a quick and effective approximation.
Needs help from first the loader and then the storeage allocator.

Until you have used it and it has saved a goodly block of time it
is a feature that many just shrug and say "That's nice". They do not
realize what they are missing.

I am getting the impression from the silence of the cross postings
that undefined checking has only shown up in Fortran systems.
The exception is Salford who also have it for their C but one also
seems to notice that their C and Fortran seem to share a lot of features.