Welcome to our forums
Just out of interest, is version 7.20 64-bit? There's a hint in the note about INTEGER kind 7 being available.
That new integer is provided as a portable kind that has the same length as a pointer. It appears to be intended for readying current code containing pointers to the future 64-bit version of the compiler. In 7.20, INTEGER(kind=7) is probably the same as INTEGER(kind=3).
No, we are still working on porting to 64 bit. However, we are making good progress.
I guessed that it would probably merit a major version number change!
I think that the main focus is on jpg and png files but there may be others. There is a reasonable chance that other image formats supported by GDI+ will work but I can not find a list of these via Google.
I will need time before I can give a more detailed response.
Paul,
Is there a possibility that ISO_FORTRAN_ENV could be included in the 64 bit version. This may give a standard way of addressing KIND although I am not sure that it provides an integer kind value that automatically chooses between 32 and 64 bit pointers. It does provide names for integer and real kind that returns some recognisable portability to code.
John
This is the major overhaul of compiler for the last 20 years (last was FTN77-FTN90). And probably for the next 40 until 128bit one. Some things like optimization or most of newer Fortran Standard features could be constantly added evolutionally later but it is important not to shoot itself into the foot and not to kill critical perspective possibilities which were missing most in FTN95:
I need 64bit compiler really ASAP but ready to wait if checking for these features needs more time. Checking is really important, the FTN90 for example was also a major flop in the history of software, real Shnobel Prize winner of world crappiest junk, until FTN95 overtook it and saved the face of company. But the whole decade was needed to debug FTN95. Hope 64bit one will be bugs-free from the start.
The initial aim for the first beta version of 64 bit FTN95 will be to enable users to develop programs as before (generating 32 bit executables) but to add a 'Release x64' mode for FTN95. The aim is to make this seamless - i.e. to make it work for all existing code without modification.
Having said this there will inevitably be some exceptions but few when compared to say using ClearWin+ with a third party compiler. Some very old FTN95/FTN77 routines can not be ported whilst, at the moment, SimpePlot is not available as a 64 bit DLL.
The initial aim means that there may not be /CHECK, /OPT or even /DEBUG in the early stages though the plan is to include these in due course.
Regarding new features, our immediate focus has to be on 'porting' rather than 'developing'. This is simply because of the scale of the task and the associated need to avoid unnecessary changes to the FTN95 'frontend'.
Hopefully we will be able to work through users' requests for new features and compatibility as time goes on and a reminder of these issues at a later date would be appreciated.
If FTN95 is an 'old dog' then the initial aim is to get it to perform the same old tricks to a new audience.
I can't help but feel that Dan is a bit harsh on FTN90 as when it came out, nobody had any source code in Fortran 90 form anyway, plus the obvious defects in Fortran 90 needed to be rectified really quickly. Fortran 90 had been in gestation for a long time: it was originally known as 8X (I have Metcalf's incomprehensible book on it if anyone wants it) and for a brief moment in time it became 88 (to continue from 66 and 77) - something that probably went by the board on 1st January 1989.
As a long-time 66/77 user, my immediate reaction was that 90 was an attempt to produce a language that was as unlike Fortran as possible, and indeed, many of the facilities are a different way of doing something you could already do perfectly adequately. Deprecating some features was a way of saying that some outspoken folks on the committee didn't like them. My reactions were coloured by the fact that there was no standard for graphics (still not) and later, no standard for GUI building - things provided by FTNxx as a matter of course both in the DBOS version and then via Clearwin+.
With the benefit of hindsight, the changes in the standard were to create a consistency with the new features, but the whole raft of them simply had to make FTN90 initially less polished than FTN77: it was version 1 of all the new features - but the existing code base was of Fortran 66/77 so why did it matter so much?
Dan's list is of things that benefit some users. My list (if I had one) would put the things that would benefit most users at the top, and I can't help but feel that speedy compilation, good diagnostics, graphics and GUI are in there somewhere close to the top, and frankly, some improvements to the documentation could be there too! With the existing documentation format it is lack of completeness that bothers me most, but some other users need to be able to teach themselves Clearwin, and yet others don't understand Fortran! Even I don't consider the latter to be a solvable however good the documentation is ...
Perhaps in the light of Paul's invitation for users to provide a 'reminder', that it is time to resurrect a list of desirable things for future inclusion ...
Without /DEBUG or /CHECK i am dead 3 seconds after my pets, computer bugs or devils change a space in the program. I myself whole life do >3 typos and errors per single line 😦
Eddie, don't worry, I am sure 64bit compiler will keep all its golden features, otherwise there is no point to do upgrade, there is a lot of Fortran junk on the market for free. I was talking about added features important for survivability of this compiler basically forever as good Fortran compilers will never disappear until people stop programming.
And now i see and can bet $20 that you have not used FTN90 from its first versions. I did. That was a shock. Until now i can not get rid of some absurd i have to keep since then because i still need to keep compatibility with my older stuff. Can you imagine FORMAT not working or working on 10% of its features let alone extensions? Or when reading the comma between numbers is not recognized?
It seems that I am not very good at making things clear.
/CHECK and /DEBUG may not be in the initial beta release but they will be added before long. With the 64 bit beta, development and testing would have to be done using the 32 bit functionality - test and develop on a small scale model and run on a large scale model.
Also please don't post requests for more features etc. now. It is not a good time to do this.
Then seems i misunderstood, now it is clear. That indeed may work not bad initially.
Quoted from PaulLaidler
Having said this there will inevitably be some exceptions but few when compared to say using ClearWin+ with a third party compiler. Some very old FTN95/FTN77 routines can not be ported whilst, at the moment, SimpePlot is not available as a 64 bit DLL.
Paul: I have noted that you wrote : 'at the moment'.....does it mean that the Simpleplot 64 bits is under development?
Agustin
Not that I know of.
I will have to ask about a release date for the personal edition.
Clearwin64.dll was released some time ago. It allows you to use ClearWin+ with third party 64 bit compilers.
Thanks for the feedback John. If anyone has any experience of using the latest ClearWin+ (GDI+) feature with the additional image formats mentioned by John then please let us know.
Previously the image formats supported by ClearWin+ were (for the most part) hard-coded with the attendant maintenance problems as formats evolved.
I was reviewing this post and I thought I would give some advice on moving to Windows 64 bit Fortran.
Even in 64 bit addressing there remain some significant limits (which can mostly be overcome) : CODE and COMMON are still restricted to 2gb.
There are others, but these are the main ones referenced.
I don't know much of the CODE restriction, as I have never approached the 2gb limit for CODE and I suspect few others ever will. ( My CODE usage is typically less than 2mb )
COMMON can be a restriction for easily changing old legacy codes for larger data sets.
The way to overcome COMMON is to use ALLOCATE for large arrays. Typically these can be placed in a MODULE for global scope. There is no alternative, BUT, you will find this to be a very effective approach, as arrays can be allocated then deallocated when not required. You may find you need less memory!
There have been some improvements to ALLOCATE since Fortran 95, such as calling subroutines with an allocatable argument, but for those familiar with pre F90 memory management, the main failings of ALLOCATE is you can't allocate a very large array (the rest of memory!) then resize it when you know how big it has to be. (this can be overcome by duplicating the array or MOVE_ALLOC)
I think it is a good coding approach to move to using MODULES with ALLOCATE variables.
Another useful concept to understand is how much memory should be used. You need to understand.
**Addressable memory limit **: I don't know what it is but it is not important for now.(we said that when changing from 16 to 32 bit) It might be 128gb or more (8Tb).
**Physical memory limit **: The amount of memory installed in your PC (or the PC likely to run the program ) The run time performance declines as this is approached. It is a good practical limit.
**Virtual memory limit **: The size limit of pagefile.sys. Typically larger than physical memory but surprisingly not always! When the memory required for your program and all other programs running exceeds physical memory, some memory image (pages) are written to 'disk' to pagefile.sys. This slows down all programs running, depending on the page fault rate (memory pages transferred per second). Simplistically, the memory usage of all programs running cannot exceed the size of pagefile.sys, so this places a practical limit on the memory your program should use.
**Array addressing limit **: If you use Integer4 subscripts, your array can not have more than 2^31 elements, so you need to change to I8 subscripts for very large allocated arrays. This means real*8 arrays larger than 16gb, so not an initial problem.
Stack size : The stack size is typically limited to 1gb, so the use of large local (automatic) arrays can be a problem. Replace these with ALLOCATE is a good approach for moth 32-bit and 64-bit coding.
Cache size: Cache size is about 6mb to 10mb. While not a 64-bit limit, addressing large rank arrays the “wrong” way can lead to cache clashes and slow performance. Bigger arrays have bigger problems. All the virtual memory strategies of 70’s and 80’s remain important for good performance, as ignoring this can have dramatic performance results, forget about chasing 2x or 4x with SSE or AVX instructions; bad memory addressing can cause 10x to 100x or more performance penalties.
BLOCK DATA and initialising arrays in declaration statements. While Initialised data can be a simple approach, for large arrays, do it in an executable statement. I rarely initialise arrays in an initialisation statement and for ALLOCATABLE TYPE arrays, prefer an initialised TYPE element that I apply to the array as an executable statement.
Be aware, for large arrays, memory is not taken at ALLOCATE but when the array is used/initialised, which can defer memory availability errors occurring for very large arrays.
If you want to test FTN95_64 successfully you should remember these concepts when developing code fo
John,
You got caught by the max post size limit.
I suspect that even the fastest cpu you can buy will struggle to run other programs at the same time as anything big enough to demand 64-bit addressing, so there isn't all that much point in running it in other than on a dedicated computer.
Eddie
Eddie,
I suspect that even the fastest cpu you can buy will struggle to run other programs
That is not the case. I have a 2-core i5 with 8gb memory and am running 64-bit OpenMP tests up to 7.5gb and it runs very well. I even ran a 15.5gb test, which thrashed the paging and it ran sort of ok. I am looking to manage out of core for these large problems, using 64-bit, to compare windows paging with an solver algorithm for paging to see the difference.
When writing the review of 64-bit, I am reminded when changing from 16-bit to 32-bit in about 1993. At that time, 2gb looked to be huge. Although I was reluctant to change (to a new compiler) I soon relished the simplicity of not using an overlay linker, or describing arrays larger than 64kb as HUGE.
At the moment I am moving to a 16gb memory pc. A colleague is using 96gb, although my real limit is how much memory I am prepared to buy. I found the BBC programs on computer languages very interesting. I wonder where programming will be in even 10 years.
I am impressed that 20 year old Fortran 95 with Allocate appears to provide a good platform for 64-bit computing. FTN95 is my main development compiler, even for 64-bit; I just start with smaller test examples. I am putting error tests on all ALLOCATE commands, although these will probably not be needed for a 64-bit compiler.
John
John,
You missed the point(s).
The end of your previous post is still missing.
The 'other programs' can't be expected to run at the same time as the memory hogger, thus negating part of the point of Windows. (And not that the memory hog won't run at all. Of course it will. It rarely chews more than a few bites at any time - pun intended - and if you give it long enough it will munch through the lot.) And 8Gb isn't all that big - what about the 192 Gb monster you once mentioned. I'll bet that chomping through a matrix inversion that takes most of that isn't going to allow you to do your e mail, photo editing, Facebook and heaven knows what all at the same time.
Eddie