From: Uno on
I've been trying to develop a 64-bit gfortran capability and was hopeful
that techniques I had been using would work on a friend's laptop, but I
think I failed.

Am I correct to think that if I had 64-bit processing, then qp_preferred
would be positive:

E:\fortran_stuff>type test1.f90
implicit none

integer, parameter :: sp = selected_real_kind(1,3)
integer, parameter :: dp = selected_real_kind(15,300)
integer, parameter :: qp_preferred = selected_real_kind(30,1000)
integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
(1-sign(1,qp_preferred))/2*dp



real (kind=sp) w
real (kind=dp) y
real (kind=qp) z

w = 4.0*atan(1.0)
y = 4.0*atan(1.0)
z = 4.0*atan(1.0)

print *, sp,dp,qp_preferred,qp
print *, w,y,z
endprogram


! gfortran -Wall -Wextra test1.f90 -o out.exe

I'm not sure how related all this is, but there's the general notion
that when you're explaining what is not happening in your program, you
should explain it in terms of what you think is decreasingly relevant,
but keep on including things even when you don't understand the
implications yourself.

I got the following when I tried to fire up the same program back here
on win32 xp:

http://i48.tinypic.com/29d9pj.jpg

E:\fortran_stuff>
Dir for this script: E:\fortran_stuff\
E:\fortran_stuff> gfortran -Wall -Wextra test1.f90 -o out.exe
Access is denied.

I did *not* get the same this roadblock on a windows7 64bit machine.

q1) Is 64-bit processing sufficient to get qp on gfortran?

q2) What are other methods to determine aspects of 64-bit processing?
--
Uno
From: glen herrmannsfeldt on
Uno <merrilljensen(a)q.com> wrote:
> I've been trying to develop a 64-bit gfortran capability and was hopeful
> that techniques I had been using would work on a friend's laptop, but I
> think I failed.

> Am I correct to think that if I had 64-bit processing, then qp_preferred
> would be positive:

(snip)

> integer, parameter :: qp_preferred = selected_real_kind(30,1000)
> integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
> (1-sign(1,qp_preferred))/2*dp
(snip)

No. 64 bit processing means that the address space is greater
than 4GB. Many 32 bit machines can do 64 bit integer arithmetic,
and 64 bit floating point goes back to the 8087 that was used with
the 8086 and 8088.

There is very little hardware support for floating point types.
The x87 (generalized 8087) has an 80 bit (64 bit significand)
floating point type meant for intermediate results. Some compilers
have support for it, such as REAL*10.

IBM has supported it on the 360/85, S/370, and successors.

There are systems that will do software emulation of REAL*16.
The VAX instruction set supports it, but it is implemented as
software emulation on most processors.

There really isn't much correlation between REAL*16 and
64 bit addressing.

-- glen

From: Uno on
On 5/18/2010 8:56 PM, glen herrmannsfeldt wrote:
> Uno<merrilljensen(a)q.com> wrote:
>> I've been trying to develop a 64-bit gfortran capability and was hopeful
>> that techniques I had been using would work on a friend's laptop, but I
>> think I failed.
>
>> Am I correct to think that if I had 64-bit processing, then qp_preferred
>> would be positive:
>
> (snip)
>
>> integer, parameter :: qp_preferred = selected_real_kind(30,1000)
>> integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+&
>> (1-sign(1,qp_preferred))/2*dp
> (snip)
>
> No. 64 bit processing means that the address space is greater
> than 4GB. Many 32 bit machines can do 64 bit integer arithmetic,
> and 64 bit floating point goes back to the 8087 that was used with
> the 8086 and 8088.
>
> There is very little hardware support for floating point types.
> The x87 (generalized 8087) has an 80 bit (64 bit significand)
> floating point type meant for intermediate results. Some compilers
> have support for it, such as REAL*10.
>
> IBM has supported it on the 360/85, S/370, and successors.
>
> There are systems that will do software emulation of REAL*16.
> The VAX instruction set supports it, but it is implemented as
> software emulation on most processors.
>
> There really isn't much correlation between REAL*16 and
> 64 bit addressing.

Tja. Is 64-bit processing sufficient to have 64-bit gfortran && gcc
pointers?

--
Uno
From: steve on
On May 18, 10:16 pm, Uno <merrilljen...(a)q.com> wrote:
> On 5/18/2010 8:56 PM, glen herrmannsfeldt wrote:
>
>
>
> > Uno<merrilljen...(a)q.com>  wrote:
> >> I've been trying to develop a 64-bit gfortran capability and was hopeful
> >> that techniques I had been using would work on a friend's laptop, but I
> >> think I failed.
>
> >> Am I correct to think that if I had 64-bit processing, then qp_preferred
> >> would be positive:
>
> > (snip)
>
> >> integer, parameter :: qp_preferred = selected_real_kind(30,1000)
> >> integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+&
> >> (1-sign(1,qp_preferred))/2*dp
> > (snip)
>
> > No.  64 bit processing means that the address space is greater
> > than 4GB.  Many 32 bit machines can do 64 bit integer arithmetic,
> > and 64 bit floating point goes back to the 8087 that was used with
> > the 8086 and 8088.
>
> > There is very little hardware support for floating point types.
> > The x87 (generalized 8087) has an 80 bit (64 bit significand)
> > floating point type meant for intermediate results.  Some compilers
> > have support for it, such as REAL*10.
>
> > IBM has supported it on the 360/85, S/370, and successors.
>
> > There are systems that will do software emulation of REAL*16.
> > The VAX instruction set supports it, but it is implemented as
> > software emulation on most processors.
>
> > There really isn't much correlation between REAL*16 and
> > 64 bit addressing.
>
> Tja. Is 64-bit processing sufficient to have 64-bit gfortran && gcc
> pointers?
>
> --
> Uno

From: steve on
On May 18, 9:25 pm, Uno <merrilljen...(a)q.com> wrote:
> I've been trying to develop a 64-bit gfortran capability and was hopeful
> that techniques I had been using would work on a friend's laptop, but I
> think I failed.
>
> Am I correct to think that if I had 64-bit processing, then qp_preferred
> would be positive:
>
> E:\fortran_stuff>type test1.f90
> implicit none
>
> integer, parameter :: sp = selected_real_kind(1,3)
> integer, parameter :: dp = selected_real_kind(15,300)
> integer, parameter :: qp_preferred = selected_real_kind(30,1000)
> integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
> (1-sign(1,qp_preferred))/2*dp
>
> real (kind=sp) w
> real (kind=dp) y
> real (kind=qp) z
>
> w = 4.0*atan(1.0)
> y = 4.0*atan(1.0)
> z = 4.0*atan(1.0)
>
> print *, sp,dp,qp_preferred,qp
> print *, w,y,z
> endprogram
>

Interpreting your vague "64-bit processing" to mean compiling
and run code on an X86_64 cpu, then no, you are not correct.

Read the Standard about the return values of selected_real_kind.

program my_kinds
implicit none
integer i
do i = 1, 20
print '(A,I0,A,I0)', 'p = ', i, ', kind = ',
selected_real_kind(p=i)
end do
do i = 7, 20
print '(A,I0,A,I0)', 'r = 1000, p = ', i, &
& ', kind = ', selected_real_kind(p=i, r=1000)
end do
end program my_kinds


--
steve