reasons for failure
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
From: Uno on 19 May 2010 00:25 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 18 May 2010 23:56 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 19 May 2010 01:16 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 19 May 2010 01:53 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 19 May 2010 02:07
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 |