Home > Archive > Fortran > May 2006 > Checking for Undefined [was Re: Ada vs Fortran for scientific applications]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Checking for Undefined [was Re: Ada vs Fortran for scientific applications]
|
|
| Bob Lidral 2006-05-25, 7:04 pm |
| 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
| |
| Nasser Abbasi 2006-05-25, 7:04 pm |
|
"Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
news:4475DA0F.5030603@comcast.net...
> Gordon Sande wrote:
>
> 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).
hi,
fyi, Matlab supports NAN's, and it has Inf and -Inf (infinities)
[color=darkred]
Warning: Divide by zero.[color=darkred]
a =
Inf
[color=darkred]
ans =
NaN
[color=darkred]
ans =
-Inf
Mathematica also:
In[12]:= 1./0;
(warning displayed like in Matlab)
Out[13]= ComplexInfinity
Nasser
| |
| Gordon Sande 2006-05-25, 7:04 pm |
| On 2006-05-25 13:23:43 -0300, Bob Lidral <l1dralspamba1t@comcast.net> said:
> Gordon Sande wrote:
>
> 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.
| |
| Thomas Koenig 2006-05-25, 7:04 pm |
| Gordon Sande <g.sande@worldnet.att.net> wrote:
>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!
I don't understand this. Do you mean INTENT (OUT)?
>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.
Oh, yes. I have used this feature on MIPS (-trapuv), and have
sorely missed it on the compilers I've used since.
| |
| Gordon Sande 2006-05-25, 7:04 pm |
| On 2006-05-25 15:30:42 -0300, Thomas Koenig <Thomas.Koenig@online.de> said:
> Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
> I don't understand this. Do you mean INTENT (OUT)?
Oops! You have the correct version.
>
>
> Oh, yes. I have used this feature on MIPS (-trapuv), and have
> sorely missed it on the compilers I've used since.
| |
| AeroSpace Ed 2006-05-25, 10:01 pm |
| Hi,
I think you might have missed the point of the NaN discussion. It wasn't
about the language being able to represent it, but by using such a bit
pattern to detect an access to a memory location that had never been set by
the program.
Ed
Nasser Abbasi wrote:
>
> "Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
> news:4475DA0F.5030603@comcast.net...
>
>
> hi,
>
> fyi, Matlab supports NAN's, and it has Inf and -Inf (infinities)
>
> Warning: Divide by zero.
> a =
> Inf
>
> ans =
> NaN
>
> ans =
> -Inf
>
> Mathematica also:
>
> In[12]:= 1./0;
> (warning displayed like in Matlab)
>
> Out[13]= ComplexInfinity
>
>
> Nasser
|
|
|
|
|