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

[Bob Lidral <l1dralspamba1t@comcast.net>]

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