large constants in expressions of type integer*8

[NimbUs]

Hi ! Using the 'g77' incarnation of Fortran. My program wants
to do integer arithmetic on 64-bit signed integers, of type :
INTEGER*8 - with intended target being X86-PC (portability not
a goal here : my algorithms may rely on internal
representation, viz, 64-bit 2's complement).
I need to specify constants of this type and use them in
simple arithmetic operations. Like so (non working example) :
C ----------------------------------
IMPLICIT INTEGER*8 (A-Z)
X = X + Z'5555555555555555'
C ----------------------------------

The intended effect of the above assignment is, I hope, clear.
However, as is, the compiler flags it as an error. I tried
putting the 'Z' specifier /after/ instead of before the hex
constant, and a couple other variations, all yielding compile
errors.

Please help ! Is there a simplest way to write the 16-hex-
digit constant so as to make g77 happy with the syntax (and of
course, semantics : NOT have the compiler truncate the data !)

Must I use the 20-something /decimal/ digit equivalent ? Will
it work any better, or are integer constant forcefully of type
integer*4 (the default for this implementation.) ?

Must I use a 'variable' albeit constant instead of a syntactic
constant ? And if so, how do I initialize the variable with
the intended value ?

I guess I must be missing something simple, obvious, stupid.
As /you/ may have guessed, it's been very many years since I
last programmed in any sort of Fortran (50-some years,
actually).

Thanks in advance !

P.S. switching compilers and/or dialects off Fortran lineage
is totally out of the question ATM.

--
NimbUs

[Myroslav Zapukhlyak]

On Wednesday, May 24, 2017 at 11:18:43 PM UTC+2, NimbUs wrote:
> Hi ! Using the 'g77' incarnation of Fortran. My program wants
> to do integer arithmetic on 64-bit signed integers, of type :
> INTEGER*8 - with intended target being X86-PC (portability not
> a goal here : my algorithms may rely on internal
> representation, viz, 64-bit 2's complement).
> I need to specify constants of this type and use them in
> simple arithmetic operations. Like so (non working example) :

use DATA statement?

[NimbUs]

Myroslav Zapukhlyak dit dans news:00607507-b241-47cb-85c8-
850a7f...@googlegroups.com:

> On Wednesday, May 24, 2017 at 11:18:43 PM UTC+2, NimbUs
wrote:

> use DATA statement?

Thanks but : nope! I had tried that and a few other things, it
works /syntactically/ (no error reported) but the 16-hex-digit
constant specified is silently truncated to an integer*4 then
internally sign-extended to an integar*8, also silently :=(

It seems all integer /constants/ in source-Fortran text are
considered to be 32-bits large, without consideration of
context. Quite unintuitive and error prone in my humble
opinion. Oh well,

meanwhile I have found the following workaround, using the
(nonstandard) bit shifting /intrinsic/ :

DATA I55Z /'55555555'Z/
I55Z = ISHFT (I55Z, 32) + I55Z
C id est, '55555555 55555555'Z .
C ------------------------------------


This is resolving the roadblock I'd met, if not fully
satisfactory. There /may/ not exist a way to specify the large
constant directly, without "calculating" it at run time ?


--
NimbUs

[robin....@gmail.com]

Try using SELECTED_INT_KIND and / or KIND.
A decimal integer constant can have the kind specified; use the _ suffix
as in 123456789098765_big
where 'big' is specified as the kind of a large integer
as in
integer (kind=kind(123456789098765)), parameter :: big = kind(1234567890987654)

[robin....@gmail.com]

On Thursday, May 25, 2017 at 9:06:48 AM UTC+10, NimbUs wrote:
> Myroslav Zapukhlyak dit dans news:00607507-b241-47cb-85c8-

> .....@googlegroups.com:

>
> > On Wednesday, May 24, 2017 at 11:18:43 PM UTC+2, NimbUs
> wrote:
>
> > use DATA statement?
>
> Thanks but : nope! I had tried that and a few other things, it
> works /syntactically/ (no error reported) but the 16-hex-digit
> constant specified is silently truncated to an integer*4 then
> internally sign-extended to an integar*8, also silently :=(
>
> It seems all integer /constants/ in source-Fortran text are
> considered to be 32-bits large, without consideration of
> context. Quite unintuitive and error prone in my humble
> opinion. Oh well,

See earlier post.

Have you tried
z'1234567890908786'_big
for a large hex constant?

[steve kargl]

robin....@gmail.com wrote:

>
> See earlier post.
>
> Have you tried
> z'1234567890908786'_big
> for a large hex constant?
>

BOZ constants in Standard conforming compilers do not
take a kind type parameter suffix (i.e., your _big).

OP is using g77 and has indicated that he cannot change
this. He's best bet is to abuse DATA and EQUIVALENCE.

program foo
integer*4 i(2)
integer*8 j
data i/2*Z'55555555'/
equivalence(j,i)
print '(z16)', i
print '(z16)', j
end

--
steve

[herrman...@gmail.com]

On Wednesday, May 24, 2017 at 4:06:48 PM UTC-7, NimbUs wrote:
> Myroslav Zapukhlyak dit dans news:00607507-b241-47cb-85c8-
> 850a7f...@googlegroups.com:

(snip)

> > use DATA statement?

> Thanks but : nope! I had tried that and a few other things, it
> works /syntactically/ (no error reported) but the 16-hex-digit
> constant specified is silently truncated to an integer*4 then
> internally sign-extended to an integar*8, also silently :=(

Tradition is for it to work.

With IBM and VAX/VMS compilers you can use REAL*8 variables
in DATA statements with 16 hex digit constants. VAX might
have INTEGER*8, but IBM compilers that I know don't.

Note that the form for DATA statements in IBM and VMS is

DATA X/Z0123456776543210/

[herrman...@gmail.com]

On Wednesday, May 24, 2017 at 5:31:57 PM UTC-7, steve kargl wrote:

(snip)

> OP is using g77 and has indicated that he cannot change
> this. He's best bet is to abuse DATA and EQUIVALENCE.

> program foo
> integer*4 i(2)
> integer*8 j
> data i/2*Z'55555555'/
> equivalence(j,i)
> print '(z16)', i
> print '(z16)', j
> end

Doesn't seem so much of an abuse to me.

I suppose it is if you want numerical values, but I thought the
OP is doing bitwise operations on them.

Note that you do have to get it right for big-endian vs.
little endian machines, though. The order of array elements
will change.

[Ron Shepard]

On 5/24/17 4:18 PM, NimbUs wrote:

> C ----------------------------------
> IMPLICIT INTEGER*8 (A-Z)
> X = X + Z'5555555555555555'
> C ----------------------------------

As others have already said, if it is an integer decimal constant, then
you can append the digit string with _ik where ik is a kind value. I'm
not certain about BOZ constants however, I don't think there is a short
way to specify those. Instead, you can use the INT() intrinsic. However,
your code above looks like it might be a little more complicated. If
your actual X is a real value, then this may be a way to try to specify
a real value as a BOZ constant rather than an integer value. The
workaround in this case I think is to use the REAL() intrinsic.The
following is an example of both integer and real BOZ values.

program ikind
integer, parameter :: ik = selected_int_kind(17),
wp=selected_real_kind(14)
real(wp) :: x
integer(ik) :: j
j = int( Z'5555555555555555',ik)
x = real(Z'5555555555555555',wp)
write(*,'(a,3(i0,1x),Z16)') 'ik=', ik, 12345678901234567_ik, j, j
write(*,'(a,i0,es25.18,1x,Z16)') 'wp=', wp, x, x
end program ikind

BTW, the values of ik and wp are not portable, but the above code is
portable. Well, at least if the INT() and REAL() thing works the way I
think they do. On many compilers these constants will have a value of 8,
but DO NOT rely on that.

Just in case the above doesn't actually work the way I think, there is
also the TRANSFER() intrinsic, which can be used to move bits from one
place to another.

When I run this program on my computer, the real value is 1.19E103 and
it has the correct Z format value. That is not the kind of real value
that I would expect to see, so maybe my concern about the type of X is
wrong, maybe it really is an integer as you show. Or maybe this was run
originally on a computer with a different floating point format, such as
an IBM mainframe. If that is the case, then you will need to figure out
what exactly your program is doing and substitute in the correct real
value at that place. That is a little beyond just a language syntax issue.

$.02 -Ron Shepard

[herrman...@gmail.com]

On Wednesday, May 24, 2017 at 6:28:04 PM UTC-7, Ron Shepard wrote:
> On 5/24/17 4:18 PM, NimbUs wrote:

> > C ----------------------------------
> > IMPLICIT INTEGER*8 (A-Z)
> > X = X + Z'5555555555555555'
> > C ----------------------------------

> As others have already said, if it is an integer decimal constant, then
> you can append the digit string with _ik where ik is a kind value. I'm
> not certain about BOZ constants however, I don't think there is a short
> way to specify those.

Do note that the OP is using g77, a Fortran 77 compiler, though
likely with some extensions. But I suspect that Fortran 90
KIND and such are not available extensions.

Even so, if a compiler supplies INTEGER*8, and that was rare
for Fortran 77, it should allow constants appropriate for use
with it.

[kargl]

Please, go review the history of BOZ within the standard starting
with F95. Ron is correct that only way to get want OP wants
within the standing Standard is to use INT() and REAL().

--
steve

[kargl]

herrman...@gmail.com wrote:

> On Wednesday, May 24, 2017 at 5:31:57 PM UTC-7, steve kargl wrote:
>
> (snip)
>
>> OP is using g77 and has indicated that he cannot change
>> this. He's best bet is to abuse DATA and EQUIVALENCE.
>
>> program foo
>> integer*4 i(2)
>> integer*8 j
>> data i/2*Z'55555555'/
>> equivalence(j,i)
>> print '(z16)', i
>> print '(z16)', j
>> end
>
> Doesn't seem so much of an abuse to me.
>

Please see F2003, C583.

C583 (R555) If an equivalence-object is of an intrinsic type other than
default integer, default real, double precision real, default complex,
default logical, or default character, all of the objects in the
equivalence set shall be of the same type with the same kind type
parameter value.

Most compiler skip this constraint. With gfortran you need to add
an option to get a warning.

gfortran6 -o z -pedantic a.f
a.f:2:16:

integer*4 i(2)
1
Warning: GNU Extension: Nonstandard type declaration INTEGER*4 at (1)
a.f:3:16:

integer*8 j
1
Warning: GNU Extension: Nonstandard type declaration INTEGER*8 at (1)
a.f:5:19:

equivalence(j,i)
1
Warning: GNU Extension: Non-default type object or sequence j in EQUIVALENCE statement at (1) with objects of different type

--
steve

[campbel...@gmail.com]

On Thursday, May 25, 2017 at 7:18:43 AM UTC+10, NimbUs wrote:

If your g77 supports INTEGER*8, you can define your large I*8 constant as
i55z = a*b+c; where a,b and c are I*8 variables with values < 2^31
It all depends on the capability of your g77, which must at least support I*8 ?

[kargl]

herrman...@gmail.com wrote:

> On Wednesday, May 24, 2017 at 5:31:57 PM UTC-7, steve kargl wrote:
>
> (snip)
>
>> OP is using g77 and has indicated that he cannot change
>> this. He's best bet is to abuse DATA and EQUIVALENCE.
>
>> program foo
>> integer*4 i(2)
>> integer*8 j
>> data i/2*Z'55555555'/
>> equivalence(j,i)
>> print '(z16)', i
>> print '(z16)', j
>> end
>
> Doesn't seem so much of an abuse to me.
>

See F2003, C583.

--
steve

[campbel...@gmail.com]

I don't understand the relevance of F2003, C583.

Aren't we discussing what can be done with "g77" to define long integer constants > 2^31 ? ( which can be messy with any F90+ )
It doesn't have to conform to the F2003 standard but work for the compiler being used, assuming it exists.

This is much like the discussion of pre F77 DO loops in "what flavor of old fortran is this?" when the emphasis was on what could be allowed. Until F77 I never looked at a Fortran standard; only the Fortran manual supplied with the computer. They all varied back then.

I wonder about why C583 was introduced, as most of my past use of EQUIVALENCE was associated with COMMON and did involve mixed type. In those cases it was important to order variables, based on descending byte size. I have never used a compiler that has reported this as an error or warning.

John

[kargl]

campbel...@gmail.com wrote:

> On Thursday, May 25, 2017 at 12:45:16 PM UTC+10, kargl wrote:
>> herrman...@gmail.com wrote:
>>
>> > On Wednesday, May 24, 2017 at 5:31:57 PM UTC-7, steve kargl wrote:
>> >
>> > (snip)
>> >
>> >> OP is using g77 and has indicated that he cannot change
>> >> this. He's best bet is to abuse DATA and EQUIVALENCE.
>> >
>> >> program foo
>> >> integer*4 i(2)
>> >> integer*8 j
>> >> data i/2*Z'55555555'/
>> >> equivalence(j,i)
>> >> print '(z16)', i
>> >> print '(z16)', j
>> >> end
>> >
>> > Doesn't seem so much of an abuse to me.
>> >
>>
>> See F2003, C583.
>>
>

> I wonder about why C583 was introduced, as most of my past use of EQUIVALENCE was associated with COMMON and did involve mixed type. In those cases it was important to order variables, based on descending byte size. I have never used a compiler that has reported this as an error or warning.
>

troutmask:kargl[202] gfortran6 -c -pedantic a.f

[kargl]

campbel...@gmail.com wrote:

> On Thursday, May 25, 2017 at 12:45:16 PM UTC+10, kargl wrote:
>> herrman...@gmail.com wrote:
>>
>> > On Wednesday, May 24, 2017 at 5:31:57 PM UTC-7, steve kargl wrote:
>> >
>> > (snip)
>> >
>> >> OP is using g77 and has indicated that he cannot change
>> >> this. He's best bet is to abuse DATA and EQUIVALENCE.
>> >
>> >> program foo
>> >> integer*4 i(2)
>> >> integer*8 j
>> >> data i/2*Z'55555555'/
>> >> equivalence(j,i)
>> >> print '(z16)', i
>> >> print '(z16)', j
>> >> end
>> >
>> > Doesn't seem so much of an abuse to me.
>> >
>>
>> See F2003, C583.
>>
>

> I don't understand the relevance of F2003, C583.

It is easier to cite F2003 as it has numbered constraints. F95,
page 66, has

Constraint: If an equivalence-object is of an intrinsic type other than

default integer, default real, double precision real, default complex,
default logical, or default character, all of the objects in the
equivalence set shall be of the same type with the same kind type
parameter value.

Most compiler will accept the above code.

> Aren't we discussing what can be done with "g77" to define long integer
> constants > 2^31 ? ( which can be messy with any F90+ )
> It doesn't have to conform to the F2003 standard but work for the
>compiler being used, assuming it exists.

Never claimed the above had to conform. I was just pointing out to
Glen that the equivalence statement may be abusive.

--
steve

[Richard Maine]

<campbel...@gmail.com> wrote:

> I don't understand the relevance of F2003, C583.

For the OP's problem, not much, as he is using g77, which is f77 rather
thn f2003. And he is even using a nonstandard feature of g77, making
what aany version of the standard says of questionable relevance.

> I wonder about why C583 was introduced, as most of my past use of
> EQUIVALENCE was associated with COMMON and did involve mixed type.

The past and the future are different, and in this case intentionally
so. That constraint specifically excepts the cases that were valid in
f77, and it does so to keep from invalidating previously valid f77 code.
However, there are 2 reasons for disallowing such type mixing for cases
that were not covered by f77.

1. I grant this one is my personal perception rather than something
concretely provable by reference to the standard, but... I think there
was a perception that using common and equivalence for type punning like
this is a practice to be discouraged and phased out. Heck, there was at
least some feeling that all use of COMMON and EQUIVALENCE be declared
obsolescent. That notion failed to be adopted into the final standard,
but there were folk in favor of it. There remained, however, a bit of
sentiment against enhancing common and equivalence, particularly the
aspects that are not considered good practice by current thinking.
(Well, that would have been "current" of about 30 years ago when that
constraint was added, but I don't think feelings have changed much since
then.)

2. Much more concretely, to allow type punning of that sort in other
types would imply specifying the storage sizes of those other types.
That definitely was something the standard was moving away from.
That's basically the same reason that character and non-character data
was not allowed in the same common in f77. To do so would have implied
that the relative storage size of character and numeric types was fixed.

Note that the standard doesn't say that compilers can't do things like
allow all sorts of type punning via common. It just says that such type
punning (other than the cases allowed in f77) are nonstandard and thus
non-portable between compilers. Hmm. I'm not sure I'm explaining that
point well, but the standard is about things that you can expect to work
the same way on all standard conforming compilers. If expected
implementations of something are going to have different results on
different compilers, then that gets labelled as nonstandard. That
doesn't mean compilers aren't allowed to compile it (though in this
case, being a constraint, compilers are required to be able to detect
and at least warn about it), but it puts users on notice that it might
not get the same results on all systems (and might not even compile at
all on some).

--
Richard Maine
email: last name at domain . net
dimnain: summer-triangle

[Gary Scott]

:) equivalence is almost abusive by definition. A typical use is for
type cheating operations of course

[NimbUs]

Thanks /all/ for your assistance and even extra-developments !

>> to do integer arithmetic on 64-bit signed integers, of type
>> INTEGER*8 - with intended target being X86-PC

(....)

>> IMPLICIT INTEGER*8 (A-Z)
>> X = X + Z'5555555555555555'

>> However, as is, the compiler flags it as an error. .

> If your g77 supports INTEGER*8, you can define your large I*
8 constant as
> i55z = a*b+c; where a,b and c are I*8 variables with values
< 2^31

Indeed, that would be more portable than the the bit shifting
intrinsic function - although I am not seeking portability
here. Instead, quick-prototyping numerical experiments on
(large) integers which I shall port to X86 assembly for speed
later.

> It all depends on the capability of your g77, which must at
least support I*8 ?

It does of course, even on older X86-32 (not X64-capable)
processors.

The problem has been circumscribed to there being no way to
specify an integer larger than 2**31 in magnitude directly as
a constant in an expression or statement. Solutions include
computiong the desired value, at run time, starting from
admissible constants (suh as your above proposition), or as an
alternative, if we insist on precompiled constants, playing
with EQUIVALENCE and DATA stateents as others in thread
suggested.

Closing the case !

--
NimbUs

[James Van Buskirk]

"NimbUs" wrote in message news:w2a6n4a1d...@mpro.xy...

> The problem has been circumscribed to there being no way to
> specify an integer larger than 2**31 in magnitude directly as
> a constant in an expression or statement. Solutions include
> computiong the desired value, at run time, starting from
> admissible constants (suh as your above proposition), or as an
> alternative, if we insist on precompiled constants, playing
> with EQUIVALENCE and DATA stateents as others in thread
> suggested.

> Closing the case !

Note that the KIND of an INTEGER*8 variable is 2 in g77, at least by
default. An easy way to convert a hex string to an integer value is
via a READ statement:

PROGRAM MAIN
IMPLICIT NONE
INTEGER*8 I
CHARACTER*16 TEST
TEST = '5555555555555555'
READ(TEST,'(Z16)') I
PRINT '(Z16)', I
END

It may still be possible to put such a constant in an expression
in g77. Have you tried the following with g77 and with the
-ftypeless-boz switch active?

PROGRAM MAIN
IMPLICIT NONE
INTEGER*8 I
I = INT8(Z'5555555555555555')
PRINT '(Z16)', I
END

Both of the above work in gfortran, but I don't have g77 to test.

[jfh]

On calling James's second program bigint.f g77 did this with it:

miro[~/Jfh]$ g77 -v -ftypeless-boz bigint.f
Driving: g77 -v -ftypeless-boz bigint.f -lfrtbegin -lg2c -lm -shared-libgcc
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-19.el6)
/usr/libexec/gcc/x86_64-redhat-linux/3.4.6/f771 bigint.f -quiet -dumpbase bigint.f -mtune=k8 -auxbase bigint -version -ftypeless-boz -o /tmp/ccEYSpa6.s
GNU F77 version 3.4.6 20060404 (Red Hat 3.4.6-19.el6) (x86_64-redhat-linux)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-19.el6).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
bigint.f: In program `main':
bigint.f:4:

I = INT8(Z'5555555555555555')

^
Truncating non-zero data on left side of typeless constant at (^)
miro[~/Jfh]$ ./a.out
-bash: ./a.out: No such file or directory
miro[~/Jfh]$

[robin....@gmail.com]

On Thursday, May 25, 2017 at 10:35:10 PM UTC+10, NimbUs wrote:
> Thanks /all/ for your assistance and even extra-developments !
>
> >> to do integer arithmetic on 64-bit signed integers, of type
> >> INTEGER*8 - with intended target being X86-PC
> (....)
> >> IMPLICIT INTEGER*8 (A-Z)
> >> X = X + Z'5555555555555555'
>
> >> However, as is, the compiler flags it as an error. .
>
> > If your g77 supports INTEGER*8, you can define your large I*
> 8 constant as
> > i55z = a*b+c; where a,b and c are I*8 variables with values
> < 2^31
>
> Indeed, that would be more portable than the the bit shifting
> intrinsic function - although I am not seeking portability
> here. Instead, quick-prototyping numerical experiments on
> (large) integers which I shall port to X86 assembly for speed
> later.
>
> > It all depends on the capability of your g77, which must at
> least support I*8 ?
>
> It does of course, even on older X86-32 (not X64-capable)
> processors.
>
> The problem has been circumscribed to there being no way to
> specify an integer larger than 2**31 in magnitude directly as
> a constant in an expression or statement.

I showed you how to do it in my first post in this thread.

[herrman...@gmail.com]

On Thursday, May 25, 2017 at 4:29:13 PM UTC-7, robin....@gmail.com wrote:
> On Thursday, May 25, 2017 at 10:35:10 PM UTC+10, NimbUs wrote:

(snip)

> > The problem has been circumscribed to there being no way to
> > specify an integer larger than 2**31 in magnitude directly as
> > a constant in an expression or statement.

> I showed you how to do it in my first post in this thread.

Do note, that has been said many times now, the OP is using
g77, a Fortran 77 compilers. Suggesting features from later
standards doesn't help much, unless you happen to know that they
are supported as extensions in older compilers.

It is a little unusual for a Fortan 77 compiler to support
INTEGER*8, but it seems that the OP has one that does.

There might even be compilers that allow for some operations,
but not all of them, on INTEGER*8.

[herrman...@gmail.com]

On Wednesday, May 24, 2017 at 7:27:41 PM UTC-7, kargl wrote:

(snip, someone wrote)

> >> OP is using g77 and has indicated that he cannot change
> >> this. He's best bet is to abuse DATA and EQUIVALENCE.

> >> program foo
> >> integer*4 i(2)
> >> integer*8 j
> >> data i/2*Z'55555555'/
> >> equivalence(j,i)
> >> print '(z16)', i
> >> print '(z16)', j
> >> end

(previous snip regarding abuse of EQUIVALENCE)

> > Doesn't seem so much of an abuse to me.

> Please see F2003, C583.

> C583 (R555) If an equivalence-object is of an intrinsic type other than
> default integer, default real, double precision real, default complex,
> default logical, or default character, all of the objects in the
> equivalence set shall be of the same type with the same kind type
> parameter value.

EQUIVALENCE between, for example, INTEGER and REAL depends on the
storage format for both. That makes it especially non-portable.

According to the VAX Fortran manual from June 88, by which time
there might have been much work toward Fortran 90, octal and hex
constants have no type. It seems, then, that they can never be used
with a variable of the same type, or, conversely, can be used with
all types.

As well as I remember earlier VAX compilers, they use the IBM format
for hex constants, Zxxxxxxxx, but in June 88 they use 'xxxxxxxx'X
where the x are hex digits. VAX does use the Z format descriptor,
as X has been already taken.

The manual also allows up to 128 bits (I suspect for REAL*16) and
explains both zero pad and truncation on the left, if the size is
wrong.

Note that I said "Doesn't seem so much of an abuse to me",
not no abuse. EQUIVALENCE with integers of different sizes should
be fairly obvious, though it does depend on knowing the size, and
also the endianness. The OP is specifically trying to initialize
a different size, but does need to watch endianness.

Initializing REAL constants for VAX is especially interesting,
as they are stored in big endian order of little endian (16 bit)
words. Hex constants, as when initializing integers, do it in
little endian order.

[Ron Shepard]

On 5/25/17 11:38 PM, herrman...@gmail.com wrote:
> The OP is specifically trying to initialize
> a different size, but does need to watch endianness.

In general that would be true, but in this case, both halves are being
initialized to the same bit pattern, so it doesn't seem like endian
conventions would ever matter.

$.02 -Ron Shepard

[herrman...@gmail.com]

On Thursday, May 25, 2017 at 10:25:07 PM UTC-7, Ron Shepard wrote:

(snip, I wrote)

> > The OP is specifically trying to initialize
> > a different size, but does need to watch endianness.

> In general that would be true, but in this case, both halves are being
> initialized to the same bit pattern, so it doesn't seem like endian
> conventions would ever matter.

It is, but I suspect that was just a test, and that the real
data might be different.

This is a little unusual, as many of the uses for 64 bit integer
arithmetic don't need big constants. My favorite one is scaling
a 32 bit value by the ratio of two 32 bit values, which needs
a multiply with a 64 bit product, and divide with 64 bit
dividend. I have also done the sum of squares of some large
integers, which also gets big, but again no big constants.

[NimbUs]

jfh dit dans news:5d613b65-0cdd-402b-853d-51e5bd0036f6
@googlegroups.com:

> On calling James's second program bigint.f g77 did this with
it:

> bigint.f: In program `main':
> bigint.f:4:
> I = INT8(Z'5555555555555555')
> ^
> Truncating non-zero data on left side of typeless constant
at (^)

Ditto. James's second method yields the somwhat cryptic error
and /no/ compiled executable is produced :=( IF it had worked
it might've been the "best" answer to the question posed in
the OP, in a sense.

Jame's first method - using internal in/out to convert big
ints from their character representation - is OK.

Just curious, what does the word "boz" mean / stand for ?

--
NimbUs

[NimbUs]

herrman...@gmail.com dit dans news:cd8cf80a-8b8a-4a37-
9bad-70a...@googlegroups.com:

> On Thursday, May 25, 2017 at 4:29:13 PM UTC-7, robin....
@gmail.com wrote:

> (snip)

>> I showed you how to do it in my first post in this thread.

@Robin : that would be as you wrote /quote/ :

A decimal integer constant can have the kind specified; use
the _ suffix as in
123456789098765_big

/quote end/

But as noted by Herrmannsfeldt and impied several times in
thread, "g77" does /not/ understand the construct, which IIUW
is in the F90 standard.

> Do note, that has been said many times now, the OP is using
> g77, a Fortran 77 compilers. Suggesting features from later
> standards doesn't help much, unless you happen to know that
they
> are supported as extensions in older compilers.

> It is a little unusual for a Fortan 77 compiler to support
> INTEGER*8, but it seems that the OP has one that does.

Correct ! g77 supports the arithmetic type INTEGER*8 but the
language offers no means to denote a constant value of this
type

> There might even be compilers that allow for some
operations,
> but not all of them, on INTEGER*8.

--
NimbUs

[mecej4]

On 5/26/2017 4:46 AM, NimbUs wrote:
<---CUT--->>

> Just curious, what does the word "boz" mean / stand for ?
>

The prefixes for strings of binary, octal and hexadecimal digit strings:

B: binary, as in B'01001000'
O: octal, as in O'76543210'
Z: hexadecimal, as in Z'0123456789ABCDEF'

Prefixes 'H' and 'X' had already been used in Fortran for other purposes
well before byte-oriented architectures appeared -- H for Hollerith and
X for blanks in format specifications.

-- mecej4

mecej...@nospam.invalid
(Replace four by 4, nospam by operamail, invalid by com,
and remove all underscores)

[NimbUs]

mecej4 dit dans news:og91qu$mnb$1...@dont-email.me:

>> Just curious, what does the word "boz" mean / stand for ?

> The prefixes for strings of binary, octal and hexadecimal
digit strings:
>
> B: binary, as in B'01001000'
> O: octal, as in O'76543210'
> Z: hexadecimal, as in Z'0123456789ABCDEF'

Oh, now I see ! Thanks ! Had wrongly supputed "boz" might be
an element of US slang or folk... Bozzo the clown...? :=)

> X for blanks in format specifications.

Off topic here BUT... it is annoying me that Fortran compilers
(follwing, I suppose, standards) nowadays /require/ a comma
following the X in formats. I am sure I'm not just senile when
I recall old fromat specs like FORMAT (5XI6) in (pre-66)
FORTRAN ! In fact I believe the normative form was that
specifiers s.a. X, T, which ended in a letter NOT be followed
by a comma.
Given that in general, Fortran standards have strived to
retain compilability of programs written in older dialects of
the FORTRAN language, Is there a reason why compilers will
flag this particular case as a /hard error/ instead of, at
most, a benign /warning/ ?

--
NimbUs

[mecej4]

On 5/26/2017 6:43 AM, NimbUs wrote:
>> X for blanks in format specifications.
>
> Off topic here BUT... it is annoying me that Fortran compilers
> (follwing, I suppose, standards) nowadays /require/ a comma
> following the X in formats. I am sure I'm not just senile when
> I recall old fromat specs like FORMAT (5XI6) in (pre-66)
> FORTRAN ! In fact I believe the normative form was that
> specifiers s.a. X, T, which ended in a letter NOT be followed
> by a comma.
> Given that in general, Fortran standards have strived to
> retain compilability of programs written in older dialects of
> the FORTRAN language, Is there a reason why compilers will
> flag this particular case as a /hard error/ instead of, at
> most, a benign /warning/ ?
>

I am not aware that this is a problem. Can you show some examples and
name the compilers that gave you trouble?

There are many places where, for certain combinations of format
specifiers, a comma may be needed to resolve ambiguities. Consider, for
example, the following code snippet:

x = sqrt(float(i))
write(*,10)i,x
10 format(/2xt42i3,2xE12.3)

The 'X' takes a numerical prefix, whereas the 'T' takes a numerical
suffix. Note the ambiguity of T42I3: is that "T42, I3", or "T4, 2I3"?
Note the comma between "I3" and "2X". Could it be left out?

Many compilers postpone parsing of the format string to run time. I
prefer a compile time error/warning to program aborts or output
containing lots of astesisks.

[NimbUs]

mecej4 dit dans news:og97fo$9it$1...@dont-email.me:

> On 5/26/2017 6:43 AM, NimbUs wrote:
>>> X for blanks in format specifications.
>>
>> Off topic here BUT... it is annoying me that Fortran
compilers
>> (follwing, I suppose, standards) nowadays /require/ a comma
>> following the X in formats.

(...snip...)

>> Given that in general, Fortran standards have strived to
>> retain compilability of programs written in older dialects
of
>> the FORTRAN language, Is there a reason why compilers will
>> flag this particular case as a /hard error/ instead of, at
>> most, a benign /warning/ ?


> I am not aware that this is a problem. Can you show some
examples and
> name the compilers that gave you trouble?

Well, GNU g77 flags things s.a. "FORMAT(1XI8)" as an error and
it is fatal at the compilation stage (not just a warning).
It's admittedly not a biggie, just an annoyance in that it
will force revising old sources for apparently no sound
reason.

I agree that /allowing/ a comma where it was not previously
required and even possibly illegal is a good thing. I do
object to treating its absence as a fatal error in places
where it does not create ambiguity.

> There are many places where, for certain combinations of
format
> specifiers, a comma may be needed to resolve ambiguities.

(...)
I grasp that, and my bad for erroneously mentionning the "T"
format specifier in this context. Those which would not (and,
in old times, must not) be followed by a comma are (used to
be) the specifiers that do not take a numerical suffix. Off my
head that would be mainly "nX", "/" and also "n(...)" groups.

> Many compilers postpone parsing of the format string to run
time. I
> prefer a compile time error/warning to program aborts or
output
> containing lots of astesisks.

Since Fortran has always been allowing format strings that are
dynamicly assembled, for good or evil, the run time flagging
of syntax errors in formats is unavoidable anyway :=)

Regards

--
NimbUs

[herrman...@gmail.com]

On Friday, May 26, 2017 at 4:43:24 AM UTC-7, NimbUs wrote:

(snip)

> Off topic here BUT... it is annoying me that Fortran compilers
> (follwing, I suppose, standards) nowadays /require/ a comma
> following the X in formats. I am sure I'm not just senile when
> I recall old fromat specs like FORMAT (5XI6) in (pre-66)
> FORTRAN ! In fact I believe the normative form was that
> specifiers s.a. X, T, which ended in a letter NOT be followed
> by a comma.

As well as I know, that comma has always been required, though
some compilers don't require it, as an extension.

Commas are not required around / which, in addition to comma,
is a separator, but I believe that they are allowed.

[herrman...@gmail.com]

On Friday, May 26, 2017 at 4:03:11 AM UTC-7, mecej4 wrote:
> On 5/26/2017 4:46 AM, NimbUs wrote:

> > Just curious, what does the word "boz" mean / stand for ?

> The prefixes for strings of binary, octal and hexadecimal digit strings:

> B: binary, as in B'01001000'
> O: octal, as in O'76543210'
> Z: hexadecimal, as in Z'0123456789ABCDEF'

> Prefixes 'H' and 'X' had already been used in Fortran for other purposes
> well before byte-oriented architectures appeared -- H for Hollerith and
> X for blanks in format specifications.

The H and X format codes were taken, and, as far as I know, it
is IBM that introduced Z format and Z constants.

As I noted earlier, a VAX compiler uses trailing X for hex
constants.

The IBM OS/360 form, allowed only in DATA statements, uses a
Z prefix and no apostrophes. It is unambiguous in DATA
statements, but would be ambiguous other places: Zxxxx

Otherwise, I might have expected IBM to use the X'xxxx' form
that OS/360 assemblers use.

IBM compilers I know don't accept B or O constants.

DEC compilers from before VAX allowed for octal constants
and O format descriptor. DEC added hex constants and format
starting with the VAX compilers. There is a story that DEC
had internal calendars with dates in hex as part of the
development of VAX.