Viewing REAL values in Hex Format
Author Message
Viewing REAL values in Hex Format

Apparently the F90 Standard supports output of the values of
Integer variables in Hexadecimal format(Z format descriptor),
but not the values of Real variables.

That is:
Integer :: x
x=1
write(*,fmt="(1X,Z16)") x
end

is correct. but

Real :: x
x=1.0+Epsilon(x)
write(*,fmt="(1X,Z16)") x
end

is not.

How can one display the internal value of real variables
(in 5 lines or less without depending on compiler extensions)?

Thanks.
Skip Knoble

Tue, 22 Jul 2008 22:49:50 GMT
Viewing REAL values in Hex Format
Hi,

<snip>

Quote:
> How can one display the internal value of real variables
> (in 5 lines or less without depending on compiler extensions)?

I suppose the most direct approach is something
along the lines of

transfer( <real-thingo>, <int-thingo>)

with appropriate care to the sizes of things.  :-)

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Tue, 22 Jul 2008 22:56:55 GMT
Viewing REAL values in Hex Format

Quote:

> Apparently the F90 Standard supports output of the values of
> Integer variables in Hexadecimal format(Z format descriptor),
> but not the values of Real variables.

> That is:
>  Integer :: x
>  x=1
>  write(*,fmt="(1X,Z16)") x
>  end

> is correct. but

>   Real :: x
>   x=1.0+Epsilon(x)
>   write(*,fmt="(1X,Z16)") x
>   end

> is not.

> How can one display the internal value of real variables
> (in 5 lines or less without depending on compiler extensions)?

> Thanks.
> Skip Knoble

I know that the powers that be are {*filter*}ly antagonistic to it, but
isn't this a case where the EQUIVALENCE statement is useful:

REAL :: X
INTEGER :: I
EQUIVALENCE ( I, X )
X = 1.0 + Epsilon(X)
WRITE ( *, '(1X,Z16)' ) I

Assuming X and I require the same storage

Dave Flower

Tue, 22 Jul 2008 23:22:17 GMT
Viewing REAL values in Hex Format

Quote:
> REAL :: X
> INTEGER :: I
> Assuming X and I require the same storage

which is guaranteed by the standard.

Joost

Tue, 22 Jul 2008 23:35:59 GMT
Viewing REAL values in Hex Format

Quote:

>> REAL :: X
>> INTEGER :: I
>> Assuming X and I require the same storage

> which is guaranteed by the standard.

Standard also says that I is undefined though most
compilers will do what the programmer wants.

--
Steve

Wed, 23 Jul 2008 01:04:42 GMT
Viewing REAL values in Hex Format

Quote:

>>> REAL :: X
>>> INTEGER :: I
>>> Assuming X and I require the same storage
>> which is guaranteed by the standard.
> Standard also says that I is undefined though most
> compilers will do what the programmer wants.

It is, at least, undefined in the sense that the standard
doesn't give any guarantees of what the value will be.

Note, for example, some systems have a different endianness
for integer and real values.  Integers could be sign
in any radix greater than one.

There might be illegal bit patterns in either integer or
real format, too.

The standard allows for that, though you won't find any
of those on most modern machines.

-- glen

Wed, 23 Jul 2008 01:52:26 GMT
Viewing REAL values in Hex Format

Quote:

> >>> REAL :: X
> >>> INTEGER :: I
> >>> Assuming X and I require the same storage

> >> which is guaranteed by the standard.

> > Standard also says that I is undefined though most
> > compilers will do what the programmer wants.

> It is, at least, undefined in the sense that the standard
> doesn't give any guarantees of what the value will be.

No, that's not what the standard means by "undefined". That is likely to
be the practical effect in the large majority of cases, but that is
distinctly not the standard's definition, and that is not the effect in
all cases.

In the standard, "undefined" means that it is not allowed for a program
to reference the variable. Thus the concept of a value for it is
irrelevant, as you can't validly tell. Yes, it is often the case that
the standard says something is undefined in order to allow different
processors to get different results. This is an awful lot like
"processor dependent". The distinction is that if a result is processor
dependent, it is standard conforming for a program to at least look and
see what the result was. For undefined, that is not standard conforming.

There exist implementations and situations where attempting to reference
an undefined variable can in practice cause things other than retrieving
a value at all. For example, you could get an error abort.

Now you aren't likely to have that happen in this case. I'm not at all
sure that there exist any compilers that do that. (Salford allegedly
does darned well at detecting undefined variables, but from the
description of how it is implemented, I wouldn't expect it to catch this
case). But that is still what the standard says about it.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Wed, 23 Jul 2008 02:08:48 GMT
Viewing REAL values in Hex Format
Dan: Thanks. what if <real-thing> is double precion real-thing?
In this case an <integer-thing> would not be the correct size
(as you cautioned).

Skip

-|Hi,
-|
-|<snip>
-|
-|> How can one display the internal value of real variables
-|> (in 5 lines or less without depending on compiler extensions)?
-|
-|I suppose the most direct approach is something
-|along the lines of
-|
-|transfer( <real-thingo>, <int-thingo>)
-|
-|with appropriate care to the sizes of things.  :-)

Wed, 23 Jul 2008 02:14:21 GMT
Viewing REAL values in Hex Format

Quote:
> Dan: Thanks. what if <real-thing> is double precion real-thing?
> In this case an <integer-thing> would not be the correct size
> (as you cautioned).

Well, default integer would not be correct, but there might be a
nondefault one that is. (Note my "might"). I assume that was part of
Dan's "appropriate care when he said

Quote:
> -|with appropriate care to the sizes of things.  :-)

Another option would be for the integer thing to be an array. For the
current purposes, that would work.

Yes, this is rife with issues that are processor-dependent. Machines of
different byte sex will end up with different parts in the array
elements. But, given "appropriate care" to the machine-dependent
elements, it ought to work.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Wed, 23 Jul 2008 02:30:04 GMT
Viewing REAL values in Hex Format

Quote:
glen herrmannsfeldt writes:
> Note, for example, some systems have a different endianness
> for integer and real values.

First I've heard of that!  Can you give an example?

Wed, 23 Jul 2008 02:38:23 GMT
Viewing REAL values in Hex Format
Hello,

Quote:

> Dan: Thanks. what if <real-thing> is double precion real-thing?
> In this case an <integer-thing> would not be the correct size
> (as you cautioned).

integer, dimension( 2) :: whatmeworry

HTH

Quote:
> Skip

> -|Hi,
> -|

> -|<snip>
> -|
> -|> How can one display the internal value of real variables
> -|> (in 5 lines or less without depending on compiler extensions)?
> -|
> -|I suppose the most direct approach is something
> -|along the lines of
> -|
> -|transfer( <real-thingo>, <int-thingo>)
> -|
> -|with appropriate care to the sizes of things.  :-)

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Wed, 23 Jul 2008 02:50:59 GMT
Viewing REAL values in Hex Format

Quote:

>> It is, at least, undefined in the sense that the standard
>> doesn't give any guarantees of what the value will be.
> No, that's not what the standard means by "undefined". That is likely to
> be the practical effect in the large majority of cases, but that is
> distinctly not the standard's definition, and that is not the effect in
> all cases.

I did say "at least".  There are definitely other things that
are possible, but I tried to point out some things that could
happen where one can read the value but it would be different
than one might expect.

VAX floating point is not big-endian or little-endian, so
even though you can EQUIVALENCE to INTEGER and print in hex,
you will be surprised to see the result.  Similar hex
values would be needed for any Z constants, too!

Quote:
> In the standard, "undefined" means that it is not allowed for a program
> to reference the variable. Thus the concept of a value for it is
> irrelevant, as you can't validly tell. Yes, it is often the case that
> the standard says something is undefined in order to allow different
> processors to get different results. This is an awful lot like
> "processor dependent". The distinction is that if a result is processor
> dependent, it is standard conforming for a program to at least look and
> see what the result was. For undefined, that is not standard conforming.

The C standard has similar definitions, resulting in a lot of
discussion on comp.lang.c.  Once one knows that it is non-standard,
and so non-portable, and decides to do it anyway, one should have
some idea what the possible results might be.

Quote:
> There exist implementations and situations where attempting to reference
> an undefined variable can in practice cause things other than retrieving
> a value at all. For example, you could get an error abort.

That is possible.  I thought I mentioned that there might be some bit
patterns that were invalid.  Some possibilities are negative zero
on ones complement and sign magnitude machines. Also, signalling NAN
in IEEE floating point can generate an interrupt when it is used.
(Maybe only when used in  a floating point operation.)

Quote:
> Now you aren't likely to have that happen in this case. I'm not at all
> sure that there exist any compilers that do that. (Salford allegedly
> does darned well at detecting undefined variables, but from the
> description of how it is implemented, I wouldn't expect it to catch this
> case). But that is still what the standard says about it.

WATFIV detects undefined values by setting all variables to a
specific bit pattern, and checking for that on reference.
This works pretty well for most variables, but for CHARACTER*1 the
chance of using that pattern is fairly high.

I did wonder before about a C compiler to generate JVM (Java Virtual
Machine) code, and it might also be interesting to do from a fortran
compiler.  JVM doesn't allow references to storage of the wrong
size or type at all, though there are ways to do the conversion
when it is needed.

-- glen

Wed, 23 Jul 2008 04:22:45 GMT
Viewing REAL values in Hex Format

Quote:

> > Now you aren't likely to have that happen in this case. I'm not at all
> > sure that there exist any compilers that do that. (Salford allegedly
> > does darned well at detecting undefined variables, but from the
> > description of how it is implemented, I wouldn't expect it to catch this
> > case). But that is still what the standard says about it.

> WATFIV detects undefined values by setting all variables to a
> specific bit pattern, and checking for that on reference.

I might misrecall, but I think that is also what Salford does. That's
what I had in mind in thnking that it would nor work for this case.
Unless the implementation is a lot more complicated than the "usual",
the equivalence is going to end up with the sam ebit pattern in both
variables, so you would not be able to make one as undefined and the
other not.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Wed, 23 Jul 2008 05:24:44 GMT
Viewing REAL values in Hex Format

(snip)

Quote:
>> WATFIV detects undefined values by setting all variables to a
>> specific bit pattern, and checking for that on reference.
> I might misrecall, but I think that is also what Salford does. That's
> what I had in mind in thnking that it would nor work for this case.
> Unless the implementation is a lot more complicated than the "usual",
> the equivalence is going to end up with the sam ebit pattern in both
> variables, so you would not be able to make one as undefined and the
> other not.

Rumors are that WATFOR on the 7090 set invalid parity
to variables as an initial value, and then detected the
parity error on reference.  That didn't work on S/360, so
they came up with the special undefined value, all bytes
to X'81'.

There are (or were) machines with tag bits on each memory location
indicating what type of value is stored there.  Different tag
bits might indicate integer or real, or even undefined.

-- glen

Wed, 23 Jul 2008 06:11:33 GMT
Viewing REAL values in Hex Format
On 2006-02-03 18:11:33 -0400, glen herrmannsfeldt

Quote:

> (snip)

>>> WATFIV detects undefined values by setting all variables to a
>>> specific bit pattern, and checking for that on reference.

>> I might misrecall, but I think that is also what Salford does. That's
>> what I had in mind in thnking that it would nor work for this case.
>> Unless the implementation is a lot more complicated than the "usual",
>> the equivalence is going to end up with the sam ebit pattern in both
>> variables, so you would not be able to make one as undefined and the
>> other not.

> Rumors are that WATFOR on the 7090 set invalid parity to variables as
> an initial value, and then detected the
> parity error on reference.  That didn't work on S/360, so
> they came up with the special undefined value, all bytes
> to X'81'.

> There are (or were) machines with tag bits on each memory location
> indicating what type of value is stored there.  Different tag
> bits might indicate integer or real, or even undefined.

> -- glen

IBM 7090s did not have parity check hardware.
IBM 7040s (and IBM 7044s) did have parity check hardware.
WatFor started on IBSYS on IBM 7040. The machines were almost
the same at the instruction level and WatFor could be coaxed
to run on the 7090 where it no longer had undefined variable
checking. The undefined variable checking code for the 7040
was not very large as it was take the interupt and find the

Burroughs 5000 (and 6000) as well as KDF9 were pointer-number
based operating systems that used the tagging scheme. The B6000s
were 48 bit words with 3 bit tags. The tags were mostly used for
arrays and memory protection. They allowed for variable sized segments
rather than fixed page sizes. They happily worked with virtual to real
ratios around 10 while fixed page size machines of the same era woked
with virtual to real ratios around 4. Either method bogged down when the
active virtual got too big, just the ratios were different. A couple
other variable segment implementations showed the same kind of higher
ratios before thrashing got too bad.

Wed, 23 Jul 2008 10:48:57 GMT

 Page 1 of 2 [ 25 post ] Go to page: [1] [2]

Relevant Pages