![forums.silverfrost.com Forum Index](templates/subSilver/images/logo_phpBB.gif) |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Mon Apr 22, 2019 4:29 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Apr 23, 2019 6:34 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Apr 24, 2019 10:17 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
John-Silver
![](http://i.postimg.cc/K8HMTnXq/Bart-Unrivalled-Native-Plotting256.jpg)
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Apr 27, 2019 7:27 pm Post subject: |
|
|
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 ... " |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Apr 28, 2019 7:47 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Apr 28, 2019 12:24 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
John-Silver
![](http://i.postimg.cc/K8HMTnXq/Bart-Unrivalled-Native-Plotting256.jpg)
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Mon Apr 29, 2019 9:08 pm Post subject: |
|
|
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 ... "
Last edited by John-Silver on Mon May 27, 2019 3:38 pm; edited 1 time in total |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Apr 29, 2019 10:13 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu May 30, 2019 6:07 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Jun 01, 2019 5:19 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Jun 03, 2019 9:42 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7927 Location: Salford, UK
|
Posted: Mon Jun 03, 2019 10:11 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|