forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Fortran 2003/2008
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Mon Apr 22, 2019 4:29 pm    Post subject: Reply with quote

Eddie

The default integer kind is 32 bit integers for both 32 and 64 bit mode.
At one point there was a context where there was an bug his was not the case but it should now be always true.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Tue Apr 23, 2019 6:34 am    Post subject: Reply with quote

Eddie,

The standard conforming compiler response to "I = 9223372036854775807" is to treat the constant as a default 4-byte integer and so produce the overflowed result. Fortunately in this case FTN95 provides a better result.

What integer kind should default for a 64 bit compiler is an interesting question.

Most compilers have adopted 4-byte, which is much easier for portability of 32-bit ode.

Providing an integer that copes with the 64 bit memory address is also a possible interpretation. While my earlier non-conforming recomendation for SIZE providing an 8-byte reult was a failure for the language purists, I wonder how many of them regularly use large memory programs, where the required answer is clearly 8-byte, rather than resorting to more complex syntax to get the obvious answer required.

My solution is to define all variables and not use "integer". I use "integer*4" or "integer*8" which although again offensive to some (as a Fortran extension) is a very robust, portable and concise description.
For constants, I would like to use 11_8, rather than integer(4).
When referencing FTN95.chm, I am always confused by examples like "INTEGER(4),PARAMETER::n=100" as in "vector processing via SSE/AVX"

Compilers should be more friendly, but unfortuntely the language standard does not share my view, eg
Code:
      real*8    :: x = 0.1
      integer*8 :: I = 9223372036854775807
      write (*,*) 'x = ',x
      write (*,*) 'i = ',i
      end
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1972
Location: Yateley, Hants, UK

PostPosted: Wed Apr 24, 2019 10:17 am    Post subject: Reply with quote

Quote:
What integer kind should be the default for a 64 bit compiler is an interesting question.


Of course it is. But it is only a subsidiary question as to what a 64 bit compiler is, or should be. In the present case, it means that the default addressing mode is 64 bit. In that respect it matches what a 32 bit compiler is. But the 16 bit compilers werenít limited to 16 bit addressing Ė with segmentation itís effectively 20 bits. There's also something funny about 8 bits, which wouldnít be much use to anyone, and were probably 16 bit anyway (like CPM).

The default REAL canít be 64 bits, because then there would be no DOUBLE PRECISION, and if the default INTEGER for constants is *4 while the variables are *8 (OK, Iíve oversimplified) thereís a mismatch waiting to cause mayhem. FTN95 is at least smart about this case if it's explicit enough.

The great thing about (say) DREAL and INTL is that the constants match the variables.

By the way, regarding your 32-bit ode Ė I couldnít manage one in 32-bits, but hereís one in 32 words!

Code:
I wrote my ode
  In Fortran code
    Many years ago.
But itís still fun
  To compile and run
    And get results to show.
Without the cost
   Of languages lost
    And consequential woe.


Eddie

PS You may deduce that I favour words over bytes. Cue opening line from The Go Between.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1079
Location: Aerospace Valley

PostPosted: Sat Apr 27, 2019 7:27 pm    Post subject: Reply with quote

It's all very confusing.

Paul previously wrote,
Quote:
The default integer kind is 32 bit integers for both 32 and 64 bit mode


and JohnC wrote that this chižoice by the Fortran 'grand masters' was made for 'compatability reasons.

... it may be a customer-driven decision, but it's not really a logical decision ... is it ?

what's the runtime parameter to change the default precision then ?

and why isn't there a ftn95 table showing all the relationships etween KIND values and all other formats of specifying precisions ?
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Sun Apr 28, 2019 7:47 am    Post subject: Reply with quote

JohnS,

I was only suggesting there is a problem as what is the default integer for a 64-bit system.

My suggestion is the default integer should be able to address the size of memory that is available ( I can't recall a reference for this requirement )

However Eddie has raised the impracticability of this as; given there is a default integer and real of the same size, there also has to be a double precision real available. Without a real*16 available, this implies that integer*4 and real*4 are the only possible default integer and real that can be used for Fortran 95, while complying with this aspect of the Fortran standard.

My problem is that the development in the Fortran Standard to provide sensible values requires the use of "KIND=", while I would suggest that for the 64-bit compiler "sensible values" should be automatically provided.

My past recommendation for SIZE to return a "sensible value" was not compatible with my recent suggestion for FTN95 "Supporting F03 and F08 syntax can be helpful for compatibility with other Fortran environments"
To me, it is just stupid that SIZE returns an overflowed value for a large array in 64-bit Fortran. The standard only addresses this required functionality in a clumsy way, but that is the standard !

I am just getting in early and apologizing for my new suggestions if I am sending Paul on another conflicted extension to FTN95 /64.

John
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1972
Location: Yateley, Hants, UK

PostPosted: Sun Apr 28, 2019 12:24 pm    Post subject: Reply with quote

There isnít a problem, really. The 64-bit appellation is the addressing mode, not the number of bits in a LOGICAL, INTEGER or REAL. It happens to be the number of bits in a COMPLEX, and a DOUBLE PRECISION, but thatís an accident.

Coincidentally, 32-bit meant the addressing mode, and in that case it was also coincidentally the number of bits in a LOGICAL, INTEGER or REAL. It wasnít the number of bits in a COMPLEX or a DOUBLE PRECISION.

As I pointed out, 16-bit wasnít the addressing mode Ė but then FTN95 never supported that, so we should forget it.

If one returns to the past, and ran Fortran on 16k words, using a machine where both REAL and INTEGER took 2 words, then DOUBLE PRECISION was such a luxury that it might just as well not been available (sometimes it wasnít), so it never bothers me that OPTIONS(DREAL) simply means that REAL is good enough for almost everything, whereas when REAL is REAL*4, it often isnít much use. Incidentally, DOUBLE PRECISION / REAL*8 wasnít all that useful on a machine with the sort of usable RAM that one got with an early PC.

OPTIONS(DREAL) simply means that REAL is REAL*8 and there isnít a DOUBLE PRECISION, which Iím fine with, and even 1 Gb allows for a lot of REAL*8 variables.

The integer case is a difficult one, because we use integers to calculate addresses. Hence, for a 64-bit addressing mode we have to have an INTEGER*8 type. If you are a fan of declaring the type of every variable and disapprove of IMPLICIT type, then you can declare every variable to be INTEGER*8 or however you like to do it with KIND. If you like implicit type, then use IMPLICIT INTEGER*8 Ė presumably. The problem is with constants, which are by default INTEGER*4. That probably hardly matters with most constants used in expressions, as for the commonest Ė 2, 3 etc - even INTEGER*4 is overkill. For the few integer constants where it does matter, FTN95 is smart. You, the programmer, can be smart too, and make those few integer constants into variables, like iTWO, iTHREE and iFOUR to give a few implicitly typed examples.

As to enumerating things with an integer number, the 4 billion of INTEGER*4 ought to be enough for most purposes , although perhaps not for the monks in a particular Tibetan Lamasery:

https://en.wikipedia.org/wiki/The_Nine_Billion_Names_of_God

Eddie

(PS. When I was first acquainted with the Arthur C. Clarke story, we Brits used billion to mean 10^12 not the US 10^9 which usage has overtaken us. It then seemed an even more intractable target. It seems that a Tibetan language version of Windows has existed since Vista, so the monks can jolly well get on with the job themselves).
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1079
Location: Aerospace Valley

PostPosted: Mon Apr 29, 2019 9:08 pm    Post subject: Reply with quote

I've tried reading th full version:
https://urbigenous.net/library/nine_billion_names_of_god.html
but I still don't get it !!!
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Mon May 27, 2019 3:38 pm; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1972
Location: Yateley, Hants, UK

PostPosted: Mon Apr 29, 2019 10:13 pm    Post subject: Reply with quote

John, If you had to count to 9 billion, even US billions, you'd need an integer bigger than INTEGER*4. Computers I used in the 60s used 24-bit words, and used 2 words for an INTEGER. They could hold 9 billion - even the UK 10^12 billion then in use. Two 24 bit words are effectively INTEGER*6. In other words, the job was doable back then. INTEGER*8 is overkill for that job.

Incidentally, the program would probably print out the 9-character names on a 132 column line printer, say 12 or 13 on a line, once the algorithm had found that many names, so apart from keeping count, the storage requirements were tiny. Assuming that the Tibetan character set was implemented on the lineprinter., all the algorithm had to do was to permutate all combinations and reject those that didn't make sense - the story explains that in principle not in detail.

It couldn't have been done in Fortran in 1953, but only in assembly language, and so the absence of a CHARACTER type is of no consequence.

I'm not sure that the computers of 1953 (when the story was written) were up to the job - those of the mid to late 60s certainly were.

Eddie
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Thu May 30, 2019 6:07 am    Post subject: Reply with quote

I have experimented with writing my own ISO_FORTRAN_ENV module and placed the .f90 .mod and .obj files in .../Silverfrost/FTN95../INCLUDE.

This appears to work ok, although I need different source for 32-bit and 64-bit ( could be fixed with /cpp)

My tests appear to indicate all that is needed is the .mod or .mod64 file. In my testing I don't appear to need the .obj file (which would be different for 32 and 64 bit). I hope this is correct.

I have added a few "extension" system routines, which could be a way of easily including them via USE ISO_FORTRAN_ENV, eg elapse_second and SIZEOF.
I have an adaptation of Get_Compiler_Version, but not Compiler_Options ( which I solve by defining an environment variable in make.bat : SET OPTIONS=....
My generic version SIZEOF also works !
Others could be easily included.

see the link below for first draft.

Comments welcomed and this may be the start of a solution.

John

https://www.dropbox.com/s/zupns8q60hdg39t/iso_fortran_env.f90?dl=0
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Sat Jun 01, 2019 5:19 am    Post subject: Reply with quote

For my ISO_FORTRAN_ENV .mod / .mod64 file, the compiling with USE ISO_FORTRAN_ENV appears to be ok, but linking is a problem.

It appears that I can't have contained routines, as this would require a .obj file. So my inclusion of Compiler_Version or Compiler_Options is not easy.

I also defined a generic INTERFACE for SIZEOF which appeared to work, but again the .obj component may also be required.

As for providing a /32 >.mod and /64 > .mod64, they would both require different .obj files which may require creating different named .lib files to be copied into .../Silverfrost/FTN95.. and referenced explicitly when using slink / slink64.

Still a possibility ??
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2079
Location: Sydney

PostPosted: Mon Jun 03, 2019 9:42 am    Post subject: Reply with quote

Paul,

Re: testing my iso_fortran_env module

I have got somewhere, as the linked example appears to work for 32-bit, but not for 64-bit.
If successful, the approach I am using does not require changes to FTN95 or possibly SLINK/SLINK64

Apart from defining a number of constants eg INT64 and REAL64, it also has contained routines, which could be an easy way of introducing new extension functions.

The module contains functions which appear to run ok when called from dan_test.f90 (the program to test some features).
Testing uses a number of routines from the module, including:
get_compiler_version
sizeof
elapse_second
report_available_memory
get_available_memory
Is_64_bit

The batch file "do_dan_test.bat" indicates how I tested, although the copy needs to be done as administrator. I have only tested with this one .f90 file.

The main problem is if I try to do the test using /64, then the build does not work.
I could not determine if there is a problem with the .obj file, or if it is needed for 32-bit.

Also the function Elapse_Second appears to work but not QueryPerformance_sec. This could relate to calling other routines defined in the .mod and what is in the .mod file. I turned off PRIVATE/PUBLIC to fix this but was not a fix.

Report_Available_Memory appears to work. It contains a lot of static data.

https://www.dropbox.com/s/dlba4hbiechxmse/iso_fortran_env_build.zip?dl=0
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5837
Location: Salford, UK

PostPosted: Mon Jun 03, 2019 10:11 am    Post subject: Reply with quote

John

Many thanks for your feedback. I have made a note of this for reference when we come to implement these features. At the moment I don't know whether we will be able to use your approach or take a different line.

Paul
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Page 10 of 10

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group