Hi,

I am using the 'f77' fortran compiler and was interested in knowing the
size of an integer using this compiler (is it 16-bit or 32-bit)?

Also, is there an unsigned integer in Fortran?

Thanks,

Michael

"Michael McGarry" <michael.mcgarry@gmail.com> wrote in message 
news:1150212932.065676.326250@g10g2000cwb.googlegroups.com...
> Hi,
>
> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?

It is the same size as whatever real is (by default).

>
> Also, is there an unsigned integer in Fortran?
>

No.

Regards,

Mike Metcalf

Michael McGarry wrote:
> Hi,
>
> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?
>
> Also, is there an unsigned integer in Fortran?
>
> Thanks,
>
> Michael

Some compilers (eg FTN77) have an option to specify the length of
INTEGER variables.

Many compilers use the following type statements:
      INTEGER*2 I
      INTEGER*4 J
although this is an extension to the standard.

Dave Flower

Michael McGarry <michael.mcgarry@gmail.com> wrote:

> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?

"The 'f77' fortran compiler" says essentially nothing. There are
probably hundreds of different fortran compilers named 'f77'. Integer
size depend on the compiler, so one would have to know what compiler you
are using in order to properly answer that. That means such things as
vendor name and version. Sometimes even the same vendor can have
multiple current versions that differ in this regard (for example, g95
does), or sometimes it can be changed by a compiler option.

However.... although one would need to know the actual compiler involved
to give a certain answer, the odds of 16 being the right answer are low.
There have been f77 compilers where default integers were 16 bits, but
mostly quite old ones (and it wasn't so even of most old ones).
Sometimes these compilers used 16 bits out of a 32-bit space allocation
- 32 bits of space to make equivalence and common work as required by
the standard, but only 16 bits used because that lead to simpler and
faster code on the machines it targeted.

The most common answer for today's compilers is 32 bits, but there are
also compilers where it is 64 bits. Other values have existed, but you'd
have to look pretty carefully to find machines that used them running
today. It can be done, but the odds of you happening to be onsuch a
machine are esssentially zero.

> Also, is there an unsigned integer in Fortran?

Not in the standard. Some compilers have such a thing as an extension.
It is not a common enough extension to be very portable.

-- 
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 McGarry wrote:
> Hi,
>
> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?
>
> Also, is there an unsigned integer in Fortran?
>
> Thanks,
>
> Michael

Why not run a test program and find out? [Don't write programs like
this at work. :-)]

      I=0
      J=1
   10 WRITE(*,*)I,J
      I=I+1
      J=J+J
      IF(J.NE.0) GO TO 10
      END

Maybe I+1 will give you the number of bits.

-- e-mail: epc8 at juno dot com

Michael McGarry wrote:
> Hi,
>
> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?
>
> Also, is there an unsigned integer in Fortran?

No, but some compilers confusingly have extensions that make it appear
as though an integer is unsigned in limited situations.  For example,
if you declare an 8-bit integer, you can assign it a value of 255 and
"get the right bit pattern" for an unsigned integer.  Although, if you
then use it in an expression, it will be evaluated as though signed
(confusing isn't it).

> 
> Thanks,
> 
> Michael

Michael McGarry wrote:
> Hi,
>
> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?
>
> Also, is there an unsigned integer in Fortran?

Sun Fortran supports unsigned integers.  If you are using Solaris
or Linux, you can download the latest technology preview version
of the compiler from Sun's website.

Bob Corbett

"Michael McGarry" <michael.mcgarry@gmail.com> wrote in message
news:1150212932.065676.326250@g10g2000cwb.googlegroups.com...
> Hi,
>
> I am using the 'f77' fortran compiler and was interested in knowing the
> size of an integer using this compiler (is it 16-bit or 32-bit)?

There is no set size.
A program like this should tell you.

      INTEGER J, K
      K = 1
      J = 1
10    IF (K > 0) THEN
         K = K + K
         J = J + 1
         GO TO 10
      END IF
      PRINT *, J
      END

robin wrote:
> "Michael McGarry" <michael.mcgarry@gmail.com> wrote in message
> news:1150212932.065676.326250@g10g2000cwb.googlegroups.com...
> > Hi,
> >
> > I am using the 'f77' fortran compiler and was interested in knowing the
> > size of an integer using this compiler (is it 16-bit or 32-bit)?
>
> There is no set size.
> A program like this should tell you.
>
>       INTEGER J, K
>       K = 1
>       J = 1
> 10    IF (K > 0) THEN
>          K = K + K
>          J = J + 1
>          GO TO 10
>       END IF
>       PRINT *, J
>       END

This depends on how the compiler treats INTEGER overflow.

One other trick that may work:

      INTEGER ARRAY(2)
      SIZE = LOC(ARRAY(2)) - LOC(ARRAY(1))

however, despite a history going back at least as far as FORTRAN IV,
LOC is not standard.

Alternatively, if an INTEGER*1 (or BYTE) data type is available:

INTEGER*1 ARRAY(17), I1, I2
INTEGER DEF_ARRAY(2)
EQUIVALENCE ( ARRAY, DEF_ARRAY)
EQUIVALENCE ( DEF_ARRAY(1), I1 )
EQUIVALENCE ( DEF_ARRAY(2), I2 )
DO I = 1, 17
   ARRAY(I) = I
END DO
SIZE = I2 - I1



Dave Flower

"David Flower" <DavJFlower@AOL.COM> wrote in message
news:1150297307.568212.155420@i40g2000cwc.googlegroups.com...
>
> robin wrote:
> > "Michael McGarry" <michael.mcgarry@gmail.com> wrote in message
> > news:1150212932.065676.326250@g10g2000cwb.googlegroups.com...
> > > I am using the 'f77' fortran compiler and was interested in knowing the
> > > size of an integer using this compiler (is it 16-bit or 32-bit)?
> >
> > There is no set size.
> > A program like this should tell you.
> >
> >       INTEGER J, K
> >       K = 1
> >       J = 1
> > 10    IF (K > 0) THEN
> >          K = K + K
> >          J = J + 1
> >          GO TO 10
> >       END IF
> >       PRINT *, J
> >       END
>
> This depends on how the compiler treats INTEGER overflow.

It runs on virtually every Fortran compiler,
which is more than can be said of what you proposed (LOC - non-standard)
and INTEGER*1 (not guaranteed).

robin wrote:
(snip)

> A program like this should tell you.
> 
>       INTEGER J, K
>       K = 1
>       J = 1
> 10    IF (K > 0) THEN
>          K = K + K
>          J = J + 1
>          GO TO 10
>       END IF
>       PRINT *, J
>       END

This assumes that the system uses twos complement binary
representation with specific overflow characteristics.

The Fortran standard does not require binary, nor radix
complement representation.  If you really claim to be
finding the largest value, you should do a binary search
(which doesn't imply binary arithmetic) for the largest
positive value.  You could also do a binary search for
the most negative value.

-- glen

glen herrmannsfeldt wrote:
....
> This assumes that the system uses twos complement binary
> representation with specific overflow characteristics.
>
> The Fortran standard does not require binary, nor radix
> complement representation.  If you really claim to be
> finding the largest value, you should do a binary search
> (which doesn't imply binary arithmetic) for the largest
> positive value.  You could also do a binary search for
> the most negative value.

It's even worse than that.  Since the question is about
the size of an integer, knowing the range of values only
gives you a minimum estimate of the answer.  An
implementation is not required to actually use all the
space it consumes for a given integer KIND.  An
early Cray C compiler used 64 bits for short, long, and
int (because it was a word addressed machine and
using a whole word was efficient), but it limited
short to 16-bits of content, long to 32-bits of content,
and int to 32-bits of content (because letting them
actually use all 64-bits broke too much C code that
assumed specific ranges of values for those types).

-- 
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

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:EJydnQHuQOJ3tQzZnZ2dnUVZ_sydnZ2d@comcast.com...
> robin wrote:
> (snip)
>
> > A program like this should tell you.
> >
> >       INTEGER J, K
> >       K = 1
> >       J = 1
> > 10    IF (K > 0) THEN
> >          K = K + K
> >          J = J + 1
> >          GO TO 10
> >       END IF
> >       PRINT *, J
> >       END
>
> This assumes that the system uses twos complement binary
> representation with specific overflow characteristics.
>
> The Fortran standard does not require binary, nor radix
> complement representation.

How many current Fortan compilers do you know that
do not use binary for integers?

>  If you really claim to be
> finding the largest value,

This program does not find the largest value.

> you should do a binary search
> (which doesn't imply binary arithmetic) for the largest
> positive value.  You could also do a binary search for
> the most negative value.

For what purpose?

On Wed, 14 Jun 2006 14:28:42 GMT, "robin" <robin_v@bigpond.com> wrote:

>"Michael McGarry" <michael.mcgarry@gmail.com> wrote in message
>news:1150212932.065676.326250@g10g2000cwb.googlegroups.com...
>> Hi,
>>
>> I am using the 'f77' fortran compiler and was interested in knowing the
>> size of an integer using this compiler (is it 16-bit or 32-bit)?
>
>There is no set size.
>A program like this should tell you.
>
>      INTEGER J, K
>      K = 1
>      J = 1
>10    IF (K > 0) THEN
>         K = K + K
>         J = J + 1
>         GO TO 10
>      END IF
>      PRINT *, J
>      END
>

Robin:

We are still waiting for your working F77 TRIM(0) function.

Where is it?

 

John wrote:
> Robin:
> 
> We are still waiting for your working F77 TRIM(0) function.
> 
> Where is it?

Look, would you just drop this?  The repeated baiting of Robin about 
this alledged TRIM function has become the single most obnoxious 
trolling on comp.lang.fortran, and that's saying something.  At this 
point, I could care less whether Robin has a working TRIM function or 
not or whether it's possible or not.  It doesn't make a single bit of 
difference to the price of tea in China, or anything else, and Robin is 
certainly never going to say another word on the matter -- so all you 
are doing is annoying everyone else who accidentally reads these rude 
and pointless messages.

- Brooks


-- 
The "bmoses-nospam" address is valid; no unmunging needed.

Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:

> Look, would you just drop this?  The repeated baiting of Robin about 
> this alledged TRIM function has become the single most obnoxious 
> trolling on comp.lang.fortran, and that's saying something.

Keeps tempting me to killfile the lot (I killfiled robin some time ago),
but as some of the ... ahem... guilty parties are J3 members (and one is
even the chair) that doesn't seem quite the thing to do. Though I try to
resist, I've even been guilty on occasion myself. (The last time, I'll
plead that I thought an innocent had been mislead, though I rather
suspect I might have missed an implied smiley.) Having killfiled robin,
I never respond or even see his posts directly, but I do see it when
others reply. Too bad this newsreader doesn't have an option to kill
based on the word "robin" appearing in the body (yes, I checked).

-- 
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

I am surprised nobody said that the standard size for an INTEGER
CONSTANT in F77 compilers in general, is 4 bytes in width. Having said
that, the size of an integer VARIABLE is what you set it to be. Here,
compilers may differ, but I think all F77 compilers allow 2 and 4 byte
integer variables to be defined; some even allow both signed and
unsigned 1-byte integers.

But whatever size you want, you must declare it or else you get the
current default size (usually 4-byte).
One way is of course to use  "IMPLICIT INTEGER*2 (I-N)"  , or other
starting letters for the variable name you want to have as 2-byte
integers, which is my preference in F77 work, and defining all needed
4-byte integer variables explicitly.

If anybody needs any special function, such as one referred to unkindly
by Mr Maine, you can write anything you like and include it as a
component in an additional linking library. After all, this is how my
company wrote windows-imitating general text, mouse and keyboard user
interfaces for F77 and F90.

Terence Wright
TAU Systems

> 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

I am surprised nobody said that the standard size for an INTEGER
CONSTANT in F77 compilers in general, is 4 bytes in width. Having said
that, the size of an integer VARIABLE is what you set it to be. Here,
compilers may differ, but I think all F77 compilers allow 2 and 4 byte
integer variables to be defined; some even allow both signed and
unsigned 1-byte integers.

But whatever size you want, you must declare it or else you get the
current default size (usually 4-byte).
One way is of course to use  "IMPLICIT INTEGER*2 (I-N)"  , or other
starting letters for the variable name you want to have as 2-byte
integers, which is my preference in F77 work, and defining all needed
4-byte integer variables explicitly.

If anybody needs any special function, such as one referred to unkindly
by Mr Maine, you can write anything you like and include it as a
component in an additional linking library. After all, this is how my
company wrote windows-imitating general text, mouse and keyboard user
interfaces for F77 and F90.

Terence Wright
TAU Systems

> 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

Terry <tbwright@cantv.net> wrote:

> I am surprised nobody said that the standard size for an INTEGER
> CONSTANT in F77 compilers in general, is 4 bytes in width. Having said
> that, the size of an integer VARIABLE is what you set it to be.

Well... depends on what you mean by "standard". In ISO standard f77,
there is only one size of integer and all integers are that size. This
includes constants and variables. The standard does not specify the
size; different f77 compilers definitely have had many different
possibilities, as mentioned previously in the thread. The 4-byte value
is the most common in today's compilers, which I suspect is the meaning
you are using for "standard".

In f77 compilers that support multiple integer sizes as an extension,
you can specify named constants of any of the supported sizes. However,
I'd agree that there is no way (that I know of) to explicitly specify
the size of a literal constant in the usual f77 extensions. In f90, of
course, there is.

> If anybody needs any special function, such as one referred to unkindly
> by Mr Maine

Hmm. I don't understand that reference. I was curious what special
function I had referred to at all, much less unkindly, since I didn't
recall anything that I'd describe that way. I can't see that I mentioned
any function in this thread. The closest thing I can find is an indirect
reference to the trim function. I suppose that might have been it,
though I didn't even mention the function in that post. It was more
about our troll baiters, who I was a little unkind to. (The
impossibility of doing trim in f77 can't be solved by writing it in some
other language and putting it in a library; the crux of the problem is
in referencing it, which that can't solve.)

Or maybe this was a reference to some posting in another thread. A few
possibilities there, I suppose.

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

Richard Maine wrote:
(snip regarding the size of INTEGER variables)

> Well... depends on what you mean by "standard". In ISO standard f77,
> there is only one size of integer and all integers are that size. This
> includes constants and variables. The standard does not specify the
> size; different f77 compilers definitely have had many different
> possibilities, as mentioned previously in the thread. The 4-byte value
> is the most common in today's compilers, which I suspect is the meaning
> you are using for "standard".

I am pretty sure that the DEC RT-11 Fortran compiler has 16 bit INTEGER
and 32 bit REAL, which I believe is non-standard.  There is probably
a compiler option to use 4 bytes for an INTEGER, though as I understand
it only 16 bits are actually used in numerical operations.  I believe
16 bit INTEGER and 32 bit REAL are also usual in 16 bit DOS compilers.

As far as I know, it is standard for INTEGER and REAL to be the same
size, such that arrays EQUIVALENCE together in the right way.

The IBM 704 did 16 bit integer arithmetic in 36 bit words.

> In f77 compilers that support multiple integer sizes as an extension,
> you can specify named constants of any of the supported sizes. However,
> I'd agree that there is no way (that I know of) to explicitly specify
> the size of a literal constant in the usual f77 extensions. In f90, of
> course, there is.

One could use a constant as an argument to a conversion intrinsic
function.  The compiler may or may not do the conversion at compile
time.  The time that it would matter most would be in subprogram
arguments, which otherwise wouldn't agree with the size of the
dummy variable.

Multiple sizes were also common extensions in Fortran 66 compilers.

(snip)

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I am pretty sure that the DEC RT-11 Fortran compiler has 16 bit INTEGER
> and 32 bit REAL, which I believe is non-standard.  There is probably
> a compiler option to use 4 bytes for an INTEGER, though as I understand
> it only 16 bits are actually used in numerical operations.  I believe
> 16 bit INTEGER and 32 bit REAL are also usual in 16 bit DOS compilers.
> 
> As far as I know, it is standard for INTEGER and REAL to be the same
> size, such that arrays EQUIVALENCE together in the right way.

Yes, the standard requires default real and default integer to be the
same size and yes, I've seen old DOS compilers with the combination of
16-bit integer and 32-bit real. I think the compilers were probably
nonconforming in that mode, though they might have had an option to use
32-bit integers (with a performance penalty).

But two things on the size requirement in the standard

1. Nothing requires that all the bits of the integer be constructively
used. It would be perfectly fine to have an integer that was 16 bits of
useful data and 16 bits of padding just to make things like equivalence
work.

2. The requirement only really makes a difference in storage association
contexts. It would also be valid to not bother with the above-mentioned
pad in situations where storage association was not used.

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

Richard Maine wrote:
....
> 1. Nothing requires that all the bits of the integer be constructively
> used. It would be perfectly fine to have an integer that was 16 bits
> of useful data and 16 bits of padding just to make things like
> equivalence work.

There was recently another thread mentioning that using floating
point hardware with denormalized numbers performed integer
arithmetic. There was a time that I saw hardware designs
that deliberately intended that integers be a special case of
the floating point representation.

-- 
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

James Giles <jamesgiles@worldnet.att.net> wrote:

> Richard Maine wrote:
> ...
> > 1. Nothing requires that all the bits of the integer be constructively
> > used. It would be perfectly fine to have an integer that was 16 bits
> > of useful data and 16 bits of padding just to make things like
> > equivalence work.
> 
> There was recently another thread mentioning that using floating
> point hardware with denormalized numbers performed integer
> arithmetic. There was a time that I saw hardware designs
> that deliberately intended that integers be a special case of
> the floating point representation.

Such as CDC systems. There were not even separate instructions for
integer arithmetic; the floating point instructions just recognized trhe
special case of all 0s (or all 1s) in the exponent field.

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

Richard Maine wrote:

(snip regarding the size of INTEGER and REAL variables)

> Yes, the standard requires default real and default integer to be the
> same size and yes, I've seen old DOS compilers with the combination of
> 16-bit integer and 32-bit real. I think the compilers were probably
> nonconforming in that mode, though they might have had an option to use
> 32-bit integers (with a performance penalty).

On small memory machines, it would have been considered a waste
to only use 16 bits of a 32 bit integer.  I believe that RT-11
accepted INTEGER*4 for that case, and I believe only used 16
bits, thought it might have changed in later versions.

I have also seen it claimed as an advantage for little endian
machines that you can pass the address of a 32 bit integer and
only reference the low 16 bits using that address.  I suppose
in some cases it might be an advantage, but mostly I see it as
a bug waiting to happen.

> But two things on the size requirement in the standard

> 1. Nothing requires that all the bits of the integer be constructively
> used. It would be perfectly fine to have an integer that was 16 bits of
> useful data and 16 bits of padding just to make things like equivalence
> work.

If I understand the IBM 704, 36 bits were used in index registers,
with some bits indicating the decrement amount.  For arithmetic
only 16 bits were used, among others resulting in the Fortran five
digit statement numbers.  As a 36 bit word machine, I suppose they
were also stored that way in memory.

> 2. The requirement only really makes a difference in storage association
> contexts. It would also be valid to not bother with the above-mentioned
> pad in situations where storage association was not used.

That would probably have to include subprogram arguments, but
otherwise I suppose it could be done that way.

-- glen

Richard Maine wrote:
> ...
> Such as CDC systems. There were not even separate instructions for
> integer arithmetic; the floating point instructions just recognized trhe
> special case of all 0s (or all 1s) in the exponent field.

FWIW, the 60-bit CDC systems did have hardware instructions for integer add/subtract.
It was multiply and divide that were wierd.   Mr Cray did similar things with the
Cray-1 and its followons - though some would say not as well he did in the 60-bit
systems.

Back in the olden days, I used several DEC compilers (mostly PDP-11s, but
also the PDP-8 that I wrote my first Fortran program on) that had different
sizes for integers and reals.  Obviously non-Standard.  But core memory was
small and expensive.  And address space was limited.  So larger integers were,
to many, extravagant.

The PDP-8 had such limited memory that the Fortran was basically Fortran I.
No user-written subroutines/functions, so no need for common blocks.  And
EQUIVALENCE was not supported either.  IIRC, integers were 12 bits and
reals were 36 bits.

W.