Home > Archive > Fortran > November 2005 > BOZ-literal-constant conversion?
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 |
BOZ-literal-constant conversion?
|
|
| Steven G. Kargl 2005-11-18, 7:01 pm |
| In the following program,
program test
real x
x = real(Z'80203040')
end program test
is the BOZ a data-stmt-constant? If so, I know how the BOZ
is to be converted to an integer via
Final Committee Draft for F2003, page 89:
If a data-stmt-constant is a boz-literal-constant, the corresponding
variable shall be of type integer. The boz-literal-constant is treated
as if it were an int-literal-constant with a kind-param that specifies
the representation method with the largest decimal exponent range
supported by the processor.
If the BOZ in the above code is not a data-stmt-constant, then
where in the standard is the conversion of the above BOZ to a
integer(?) defined.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| James Giles 2005-11-18, 7:01 pm |
| Steven G. Kargl wrote:
> In the following program,
>
> program test
> real x
> x = real(Z'80203040')
> end program test
>
> is the BOZ a data-stmt-constant? If so, I know how the BOZ
> is to be converted to an integer via
>
> Final Committee Draft for F2003, page 89:
>
> If a data-stmt-constant is a boz-literal-constant, the
> corresponding variable shall be of type integer. The
> boz-literal-constant is treated as if it were an
> int-literal-constant with a kind-param that specifies the
> representation method with the largest decimal exponent range
> supported by the processor.
>
> If the BOZ in the above code is not a data-stmt-constant, then
> where in the standard is the conversion of the above BOZ to a
> integer(?) defined.
In F2003 (but no sooner) the above is a special form accepted
in the type intrinsic functions. It isn't converted to an integer here,
but the bits are directly used as the value of a REAL. Since you have
the F2003 draft, see _§13.7.97.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
--
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard E Maine 2005-11-18, 7:01 pm |
| Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
....
> x = real(Z'80203040')
....
> is the BOZ a data-stmt-constant?
That one is easy. No. It isn't in a data statement, which is the only
place where the data-stmt-constant bnf appears.
> If the BOZ in the above code is not a data-stmt-constant, then
> where in the standard is the conversion of the above BOZ to a
> integer(?) defined.
In the section on the REAL intrinsic. (13.7.97, pp. 345-346).
Um, anyway that's the section that defines what the above syntax means.
I don't know what "conversion to an integer" you are talking about, as
there isn't any such thing involved here. In this context, the boz
doesn't represent an integer - just a bit pattern.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Michael Metcalf 2005-11-18, 7:01 pm |
|
"Steven G. Kargl" <kargl@troutmask.apl.washington.edu> wrote in message
news:dll9nv$jbq$1@gnus01.u.washington.edu...
> In the following program,
>
> program test
> real x
> x = real(Z'80203040')
> end program test
>
> is the BOZ a data-stmt-constant?
No, but f2003 allows BOZ constants to appear as the principal argument of
cmplx, dble, int and real, where they are treated for real as reals with the
same bit pattern on a given processor (see also "Fortran 95/2003 Explained",
Section 18.9).
Regards,
Mike Metcalf
| |
| Steven G. Kargl 2005-11-18, 7:01 pm |
| In article <1h680t4.r6dbgac0eh40N%nospam@see.signature>,
nospam@see.signature (Richard E Maine) writes:
> Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
> In the section on the REAL intrinsic. (13.7.97, pp. 345-346).
It's Friday and my caffiene levels are low. :-)
I must have read 13.14.88 from the Fortran 95 standard and
4.4.1 in Fortran 2003.
> Um, anyway that's the section that defines what the above syntax means.
> I don't know what "conversion to an integer" you are talking about, as
> there isn't any such thing involved here. In this context, the boz
> doesn't represent an integer - just a bit pattern.
The BNF for a BOZ is given under 4.4.1 "Integer Type". C410
mentions DBLE, REAL, INT, and CMPLX (without forward reference
to the appropriate sections), but C410 does not state that a
conversion to "Integer Type" does not occur. Perhaps, C410
should state that with respect to these intrinsics a BOZ is
simply a processor-dependent bit pattern.
Now, that I've read 13.7.97. I notice the dread "The interpretation
of the value of the bit pattern is processor dependent.", which means
this feature is a loaded gun.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Richard E Maine 2005-11-18, 7:01 pm |
| Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
> Now, that I've read 13.7.97. I notice the dread "The interpretation
> of the value of the bit pattern is processor dependent.", which means
> this feature is a loaded gun.
You expected anything different from a feature that allows people to
give a specific bit pattern????
Or did you think that this meant something other than that?
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Steven G. Kargl 2005-11-18, 7:01 pm |
| In article <1h689yi.y1hc1wxlwt24N%nospam@see.signature>,
nospam@see.signature (Richard E Maine) writes:
> Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
>
> You expected anything different from a feature that allows people to
> give a specific bit pattern????
No, not really. Unfortunately, as someone hacking on gfortran,
I can see the bug reports flowing in when people don't understand
little vs big endian and whether the bit pattern is padded
with zeros.
For a 32-bit real, is real(Z'ABC') 0xABC00000 or 0x00000ABC?
Are the "unset" bits undefined so real('ABC') is in a semi-defined
state? Of course, this is processor dependent.
Extending the bit manipulation intrinsics to manipulate the
significand (ie. mantissa) of a real type would seem to be
a pretty choice than the vagueness of BOZ-literal-constants.
(Yes, I know the radix is not restricted to a value of 2).
> Or did you think that this meant something other than that?
No. I'm becoming quite fond of the "processor dependent" phrase. :-)
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Gary L. Scott 2005-11-19, 6:58 pm |
| Richard E Maine wrote:
> Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
> ...
>
>
> ...
>
>
>
> That one is easy. No. It isn't in a data statement, which is the only
> place where the data-stmt-constant bnf appears.
>
>
>
>
> In the section on the REAL intrinsic. (13.7.97, pp. 345-346).
>
> Um, anyway that's the section that defines what the above syntax means.
> I don't know what "conversion to an integer" you are talking about, as
> there isn't any such thing involved here. In this context, the boz
> doesn't represent an integer - just a bit pattern.
>
I'm slightly  isn't it almost always the intent of using these
alternate number representations to try to force a specific bit pattern
on assignment? That's always my intent. Is that sort of an implied
"transfer" (set these bits in this variable...I'm trying to understand
terminology here)?
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2005-11-19, 6:58 pm |
| Gary L. Scott <garyscott@ev1.net> wrote:
> Richard E Maine wrote:
>
> I'm slightly isn't it almost always the intent of using these
> alternate number representations to try to force a specific bit pattern
> on assignment? That's always my intent. Is that sort of an implied
> "transfer" (set these bits in this variable...I'm trying to understand
> terminology here)?
Yes. That's why I didn't understand the reference to integer. There is
no integer around - just the bit pattern and the real. Though it is
possible (even likely) that people got by the fact that the
standard describes the syntax for BOZ as an integer literal constant -
that's sort of misleading when BOZ is just used as a bit pattern like
this.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2005-11-19, 6:59 pm |
| Richard Maine wrote:
> Gary L. Scott <garyscott@ev1.net> wrote:
(snip regarding BOZ constants)
[color=darkred]
> Yes. That's why I didn't understand the reference to integer. There is
> no integer around - just the bit pattern and the real. Though it is
> possible (even likely) that people got by the fact that the
> standard describes the syntax for BOZ as an integer literal constant -
> that's sort of misleading when BOZ is just used as a bit pattern like
> this.
I agree it sounds confusing, but it could also be confusing not to say
it that way. It might be the results are similar to EQUIVALENCing a
variable to an appropriate sized INTEGER variable, and then assigning
to the EQUIAVALENCEd INTEGER variable.
Consider endianness: If the destination is an INTEGER variable one still
expects the leftmost bits of a BOZ constant to be most significant,
while on a little endian machine those bits will be stored in memory in
a different order.
Even more, consider VAX. (The VAX/VMS compilers do allow Z constants, I
am not sure about B or O.) VAX is little endian, but floating point
values are stored as big endian (16 bit) words, each stored little
endian. Z constants have the appropriate representation for an INTEGER
stored in memory, the sign bit is near the middle for a REAL*4 value.
I believe, then, on byte addressed little endian machines the bytes from
a BOZ constant are stored in memory from high to low address, and this
bit pattern is then used for the floating point value, where appropriate.
For an alternative view, PL/I uses bit string constants which, similar
to character string constants, are stored left to right from low to high
address, even on a little endian machine. (Leaving open the question of
bit order within a byte.)
On the other hand, in the case of a ones complement or sign magnitude
machine, mentioning INTEGER can be confusing. It would make more sense
to describe them as unsigned integer values.
-- glen
-- glen
| |
| Ron Shepard 2005-11-19, 6:59 pm |
| In article <1h69oqc.1voojgy11h92r4N%nospam@see.signature>,
nospam@see.signature (Richard Maine) wrote:
> Yes. That's why I didn't understand the reference to integer. There is
> no integer around - just the bit pattern and the real. Though it is
> possible (even likely) that people got by the fact that the
> standard describes the syntax for BOZ as an integer literal constant -
> that's sort of misleading when BOZ is just used as a bit pattern like
> this.
I have not followed all of this discussion, but if the standard does
describe a BOZ as an integer constant, and if REAL(I) converts the
integer value of I into a real floating point value (rather than
transferring the bit pattern), this of course there will be
confusion about the meaning of REAL(Z'123').
Is this really the case? Is it too late to change this syntax to
something less confusing (perhaps using TRANSFER() rather than
REAL())?
$.02 -Ron Shepard
| |
| Richard Maine 2005-11-19, 6:59 pm |
| Ron Shepard <ron-shepard@NOSPAM.comcast.net> wrote:
> I have not followed all of this discussion, but if the standard does
> describe a BOZ as an integer constant,
It does at the moment, though that may change in future versions. They
might end up being described as BITS literals, for example.
> and if REAL(I) converts the
> integer value of I into a real floating point value (rather than
> transferring the bit pattern), this of course there will be
> confusion about the meaning of REAL(Z'123').
The meaning of REAL(boz) is distinctly a special case in several ways.
> Is it too late to change this syntax
Yes. It is in the published standard... and probably in some compilers
as well. Zero chance of it changing. If you want to add some other
syntax as well, that at least has chances, but I'd say low...
particularly as I don't see any proposal here that doesn't casue at
least as much confusion.
> something less confusing (perhaps using TRANSFER() rather than
> REAL())?
That won't be any less confusing. *ANY* attempt to describe it as a
result of interpreting the boz as an integer and then operating on that
integer will be confusing. There are all kinds of issues... including
issues of what the KIND of the integer is. What happens, for example,
when you try to apply this to reals of larger size than any supported
integer size? No, you won't find a "solution" in that direction at all.
You just end up with a syntax that is more complicated and just as
confusing.
I think a much better slution is to avoid talking about integers at all
in this context. They aren't relevant. Instead, consider the boz to be a
bit pattern, with no particular relationship to integer values implied.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Steven G. Kargl 2005-11-19, 6:59 pm |
| In article <1h69xa7.l9ovua1n9gfi8N%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:
>
> I think a much better slution is to avoid talking about integers at all
> in this context. They aren't relevant. Instead, consider the boz to be a
> bit pattern, with no particular relationship to integer values implied.
Then IMHO the description of BOZ should not be in 4.4.1.
It should be in its own section.
Additionally, instead of overloading REAL, INT, DBLE, and COMPLX,
it would have been better to have RBSET, RBCLEAR, etc just like
IBSET etc.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Gary L. Scott 2005-11-19, 6:59 pm |
| Steven G. Kargl wrote:
> In article <1h69xa7.l9ovua1n9gfi8N%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes:
>
>
>
> Then IMHO the description of BOZ should not be in 4.4.1.
> It should be in its own section.
>
> Additionally, instead of overloading REAL, INT, DBLE, and COMPLX,
> it would have been better to have RBSET, RBCLEAR, etc just like
> IBSET etc.
>
Then won't you need a cbset and cbclear (with provision for DBCS??),
because it is quite commonly applied to character values (albeit usually
equivalenced to integers and applied to the integer alias)?
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Steven G. Kargl 2005-11-19, 6:59 pm |
| In article <11nv4c6bsv3maf7@corp.supernews.com>,
"Gary L. Scott" <garyscott@ev1.net> writes:
> Steven G. Kargl wrote:
>
> Then won't you need a cbset and cbclear (with provision for DBCS??),
> because it is quite commonly applied to character values (albeit usually
> equivalenced to integers and applied to the integer alias)?
>
Last time I checked, CHARACTER was not a numeric data type. I would
limit explicit bit manipulation to numeric types. But, if you
want CBSET, what is the problem (other than no DIGITS intrinsics)?
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Gary L. Scott 2005-11-19, 6:59 pm |
| Steven G. Kargl wrote:
> In article <11nv4c6bsv3maf7@corp.supernews.com>,
> "Gary L. Scott" <garyscott@ev1.net> writes:
>
>
>
> Last time I checked, CHARACTER was not a numeric data type. I would
> limit explicit bit manipulation to numeric types. But, if you
> want CBSET, what is the problem (other than no DIGITS intrinsics)?
No problem, but if an application requires utilization of bit pattern
manipulation it is quite commonly utilized on ANY data type (one way or
another). I see no reason to limit its usefulness.
--
Gary Scott
mailto:garyscott@ev1.net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Richard Maine 2005-11-19, 9:58 pm |
| Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
> In article <1h69xa7.l9ovua1n9gfi8N%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes:
>
> Then IMHO the description of BOZ should not be in 4.4.1.
> It should be in its own section.
I'd agree. Wouldn't surprise me for this to happen in conjunction with
the BITS type. Thy woudl end up in the section on it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Ken Fairfield 2005-11-21, 7:01 pm |
| glen herrmannsfeldt wrote:
[...big snip...]
>
> Consider endianness: If the destination is an INTEGER variable one still
> expects the leftmost bits of a BOZ constant to be most significant,
> while on a little endian machine those bits will be stored in memory in
> a different order.
I don't think that's true, at least in terms of writing down
the BOZ string representation ("stored in memory" can become a
rather esoteric concept!).
On both IBM 360-style/3090-style machines (big endian), and on
VMS (little endian), one writes a BOZ constant for a 32-bit word in
the same way, left to right, with the most significant bit on the
left (or the sign bit followed by the MSB) for a standard two's
complement integer value. Indeed, the hex expression for any 8-bit
byte is identical on the two. The "endianess" comes only in the
where the address of the 32-bit word points (to the MSB on big endian,
to the LSB on little endian), the order of the 4 bytes in the 32-bit
word, and the bit-numbering conventions of the two.
> Even more, consider VAX. (The VAX/VMS compilers do allow Z constants, I
> am not sure about B or O.)
Yes, VMS Fortran supports all three (and has since my earliest
exposure to it in the early '80s).
> VAX is little endian, but floating point
> values are stored as big endian (16 bit) words, each stored little
> endian. Z constants have the appropriate representation for an INTEGER
> stored in memory, the sign bit is near the middle for a REAL*4 value.
VAX floating point is "wierd". That's a given. It has been
discussed here many times in the past. For the uninitiated, the
reason for the wierdness was to be compatible with PDP-11 (16-bit
words) floating point format, and the ramifications of that...
It might be more appropriate to talk about the 32-bit, 64-bit and
128-bit IEEE floating point formats which are fully supported on
Alpha/VMS and IA64/VMS and are also little endian...
> I believe, then, on byte addressed little endian machines the bytes from
> a BOZ constant are stored in memory from high to low address, and this
> bit pattern is then used for the floating point value, where appropriate.
Given an IEEE fp format, you'd write the BOZ string the same
for either big or little endian machines.
OTOH, if you were separately assigning the individual bytes
of a longer word, where, say, you'd equivalenced and an array of
4 bytes to a single 32-bit integer or real, you'd need to worry
about which was the most significant byte. This is not portable
being different between big and little endian (on big endian,
the MSB is in BYTE_ARRAY(1), whereas on little endian, the MSB is
in BYTE_ARRAY(4); the numeric value of the corresponding MSB, etc.,
will be the same between big and little endian).
-Ken
--
I don't speak for Intel, Intel doesn't speak for me...
Ken Fairfield
D1C Automation VMS System Support
who: kenneth dot h dot fairfield
where: intel dot com
| |
| glen herrmannsfeldt 2005-11-22, 4:00 am |
| Ken Fairfield wrote:
> glen herrmannsfeldt wrote:
> [...big snip...]
[color=darkred]
> I don't think that's true, at least in terms of writing down
> the BOZ string representation ("stored in memory" can become a
> rather esoteric concept!).
> On both IBM 360-style/3090-style machines (big endian), and on
> VMS (little endian), one writes a BOZ constant for a 32-bit word in
> the same way, left to right, with the most significant bit on the
> left (or the sign bit followed by the MSB) for a standard two's
> complement integer value. Indeed, the hex expression for any 8-bit
> byte is identical on the two. The "endianess" comes only in the
> where the address of the 32-bit word points (to the MSB on big endian,
> to the LSB on little endian), the order of the 4 bytes in the 32-bit
> word, and the bit-numbering conventions of the two.
Yes, that is what I was trying to say. The MSB is leftmost (and lowest
address) in the BOZ text representation, even if it isn't when the value
is stored in memory. (The OS/360 Fortran compilers have Z constants
and the Z format descriptor. Being big endian, it doesn't help the
discussion. IBM does describe it in term of a bit string, though.)
[color=darkred]
> Yes, VMS Fortran supports all three (and has since my earliest
> exposure to it in the early '80s).
I remember Z from VMS 1.0, but I wasn't sure about O, and even less B.
VAX was DECs first processor designed for hex. That is, instruction
fields are on four bit boundaries. I am told that they had a calendar
with the dates in hex to advertise this fact.
[color=darkred]
> VAX floating point is "wierd". That's a given. It has been
> discussed here many times in the past. For the uninitiated, the
> reason for the wierdness was to be compatible with PDP-11 (16-bit
> words) floating point format, and the ramifications of that...
> It might be more appropriate to talk about the 32-bit, 64-bit and
> 128-bit IEEE floating point formats which are fully supported on
> Alpha/VMS and IA64/VMS and are also little endian...
Alpha also supports F, D, G, and H float formats for VAX compatibility.
As far as I understand, it does this by loading them into registers such
that the bits end up in the appropriate place.
[color=darkred]
> Given an IEEE fp format, you'd write the BOZ string the same
> for either big or little endian machines.
Yes, because the BOZ values are stored as integers would be,
and assuming that the floating point format has the same endianness as
the integer format.
> OTOH, if you were separately assigning the individual bytes
> of a longer word, where, say, you'd equivalenced and an array of
> 4 bytes to a single 32-bit integer or real, you'd need to worry
> about which was the most significant byte. This is not portable
> being different between big and little endian (on big endian,
> the MSB is in BYTE_ARRAY(1), whereas on little endian, the MSB is
> in BYTE_ARRAY(4); the numeric value of the corresponding MSB, etc.,
> will be the same between big and little endian).
If you consider the BOZ constant as a bit string that would be what I
would expect. Just as with character strings on little endian machines
the leftmost bit or character goes in the low address.
It would be possible to store floating point values in big endian format
on an otherwise little endian machine, though I don't know of any
machines that do it. (It makes more sense than VAX format.)
In any case, it is not portable to machines with a different word size,
but that is a different question.
-- glen
|
|
|
|
|