Again: 64 bit Compiler

Hi John,

Yes, I did understand that coding gets easier if everything is simultaneously in memory, and it probably runs (a lot) quicker too. But if you want to use 32-bit FTN95 with all the advantages of Clearwin, then you can run a tiled application, and you can't run an un-tiled one!

So what do you think of a poll of user wishes?

Eddie

Eddie,

I agree that a poll of user wishes would be a good idea to see what users of FTN95 would like to see available.

I would also like to get some feedback from Silverfrost as to what is possible and what resources and funding can be provided. We see a lot of valuable support from Paul and others. I think a lot of this is provided by them in their 'free' time. If (say) the estimate for just getting to a 64-bit .exe is 1,000 hours, I'm sure there would be complaints if clearwin+, .net and all the library routines did not support memory addresses above 4gb. Depending on the funding model for Silverfrost, this amount of commitment could be a huge ask.

FTN95 is a very extensive system. Just look at all the enhancements for .net and Visual Clearwin, which I've never used!

I note that my copy of the Fortran 95 standard is 376 pages, while the draft of 2008 is 621 pages. There is a lot of new stuff in there to be implemented if FTN95 were to become FTN08.

Eddie, as you have asked; 'if you want to use 32-bit FTN95 with all the advantages of Clearwin' then we need to be realistic.

John

My only interests are to be able to use say 20 to 30 GB of RAM, and fast procssing destributed to all available processors. This reqires a 64-bit program.

My large optimisation programs are pure batch programs. They do not need Clearwin, or Visual Clearwin or .net.

All other programs using Clearwin may stay with 32 bits.

Erwin

Hi Erwin,

Although I'm a huge fan of FTN95, it looks to me that this set of needs is better met with a different compiler. In the DBOS days, you would have used FTN77 because it was fast and allowed access to what was then the huge memory resource of Extended Memory. I do have 2 further observations: (1) For development and debugging, FTN95 is as good as any, and better than most (assuming you do development and testing with a smaller dataset than you use for production!) (2) FTN95 [u:920e2b278e]does[/u:920e2b278e] use all the cores on a processor, because Windows makes it do so. Just look at a resource monitor screen. What you don't see is all the cores running at maximum speed - there is plenty else going on in the computer and this is the result of the hardware and OS design. I think it is a mistake to equate the lack of explicit multithreading in FTN95 with 'running on 1 core'. As Windows does multithreading, then you would only fight it if FTN95 was trying to do it at the same time. I look to Paul for agreement here!

I am composing a discussion on the speed issue - I'll start a new thread for that because it is radically different to the 64-bit issue.

Eddie

I do not have time but may be someone can start and support similar discussion in comp.lang.fortran to find the state of the art with 64bit compilers of all other companies? Interesting what is the main difficulty for devs?

Another issue. For some tasks I see potential temporal workaround by making 64bit part in different compiler and linking it with FTN95 with DLL. Can anyone try to make small sample code?

Dan,

a nice idea, but, as far as I know there is no way to combine a 64-bit DLL with a 32-bit program.

Erwin

Quoted from EKruck Dan,

a nice idea, but, as far as I know there is no way to combine a 64-bit DLL with a 32-bit program.

Erwin

Erwin

Yes there is.

You have to compile the 64-bit number crunching stuff into a DLL that establishes a reverse communication with the 32-bit code running Clearwin. That is the way that 64-bit Simfit and 64-bit Simdem work.

Bill

I am still missing any comment / remark by Silverfrost!!??!!

What do they say to shorter update times of FTN95?

What do they think of supporting 64 bit Windows? Is there any schedule to do this?

It seems they don't like our discussions and therefore they will not give any answers to our (the users) questions.

Detlef

Thank you for your input. It does help to know what our users would like to have. I am aware of this discussion and plan to respond shortly.

Paul

Hi Paul,

did you give a reply already? I have nothing heard until now.

Detlef

There are currently no plans to create a 64bit version of FTN95 nor are there plans to significantly further extend FTN95 into Fortran 200x.

However, we are investigating the possibility of making ClearWin+ accessible to third party 64bit compilers. The idea is that, for developers who need to have a 64bit addressable memory, development can be carried out on a small scale model using 32bit FTN95 with CHECKMATE and SDBG etc., then full scale models will be run using a third party 64bit compiler together with a 64bit ClearWin+ DLL.

This approach, if it works, will not meet all of the preferences that have been expressed above but will satisfy most of them. I realise that this is not a perfect solution to the problem but hopefully it will provide a way forward.

It seems that Silverfrost has decided to give up and users should migrate to Intel with their code! What a pity!

Detlef

Please do not use this Forum for negative comments about Silverfrost or its products. The Forum is provided and maintained by Silverfrost for the common good and information is provided in good faith.

We are committed to continue supporting FTN95 etc. together with CHECKMATE, SDBG and ClearWin+ etc. This will continue to provide a useful development tool for many users. In the short term the aim is to make ClearWin+ available to third party 64bit compilers so that users who need a 64bit environment can continue to take advantage of Silverfrost development and GUI tools.

I’m afraid I am with Paul on this one.

Clearwin started out as a “costs extra add-on”. In another thread, we debated whether the Clearwin code a programmer writes is legitimate Fortran, and decided that it probably was, apart from the @ character. Hence, for someone else’s Fortran with a Clearwin add on, one might write:

I = WINIOQQ (‘%ca[Shame on you]’)

instead of the familiar WINIO@. In another thread we learned that Clearwin was simply a “wrapper for the Windows API”, although it did “do some internal housekeeping”. So it looks like a sensible approach to make a compiler-independent version of it – at least an extra product that could come to market very quickly and generate revenue.

I attended a one-day workshop at Salford when Clearwin was launched, and FTN77 with DBOS struggled to make itself easy to use in Windows (95 I believe). Clearwin came into its own when DBOS was abandoned.

I won’t be deserting FTN95, even if Clearwin is available for other compilers. There are reasons for this.

FTN95 is a mature and stable product, with a long update cycle and few changes. Compare that to the error fix list for other compilers in their user support pages. Not only that, but a good proportion of the fixes are to do with Plato or enhancements to Clearwin which the other compilers do not have. Clearwin and FTN95 come from the same stable, and interface with each other smoothly Compilation is quick, and the diagnostics are excellent. I don’t use the debugger, but I understand that it too is excellent. Unlike some other users, I just don’t need those great big data spaces. Windows (and this is after 3 versions that allegedly were 64-bit) isn’t really a 64-bit operating system. Also, it seems to me that if you really do need arrays >2Gb in size, you don’t need many of them. Early in this thread I suggested that one only needed the facility to make a few 64-bit addressable arrays – perhaps as few as 4 of them, and possibly only 1 ! From my perspective of ignorance surely that can’t be too difficult.

I also think Paul is right in not plunging full speed into dealing with the latest published standard. After all, 1990 is 22 years ago, and in the bug fix list for FTN95, just look at how few (of an already small list) of those fixes relate to Fortran 77 features. Most of the bug fixes are to do with Fortran 90/95. It is inconceivable that large applications are out there waiting to be compiled with all the features of Fortran 200x. To incorporate all the new features in Fortran 200x – especially in one go - would destroy a valuable stability. My guess is that these features will arrive eventually, but will be introduced gradually.

Microsoft make the job of producing compilers hard enough in the changes they make to Windows and to Visual Studio. A big chunk of the bug fixes to FTN95 is repairing things that Microsoft broke. As developers, forum users should have sympathy - even keeping abreast of stylistic changes in Windows is a major job – and for those with no sympathy for Paul, I suggest that you go and read Kipling’s “If” (Readily available on the web).

Eddie

I like the idea of making Clearwin compiler independent. The more people will use it the more new programming features will be there, more user examples, in simple words - the better for all us. It's probably even time to think about tablet/cellphone GUI interfaces with Clearwin i also miss so much right now 😃

Still i'd like to understand why switch to 64bit for FTN95 is considered as not feasible move. Basically no any new features like Fortran F200X are needed, the 64bit FTN95 compiler will do the same things, it's all about system memory allocation which will be different. I do not know all hidden pitfalls here but, say, if the compiler is written in C isn't it possible just to recompile it with minimal changes using MS 64-bit C or GCC ( they already have their 64bit Fortran)?

Internally FTN95 contains a front end (that does the parsing etc. and creates a data base) and two back ends (one that converts the data base to 32bit assembler and another that converts the data base to .NET CLR). Creating a 64bit compiler would require an additional back end that would create 64bit assembler from the data base (or a major rewrite of the front end so that it outputs C code instead of the existing data base). That is not to mention changes that would be required to SDBG and salflibc.dll even if we adopted a third party C compiler and linker.

Paul,

More from me, I'm afraid.

Isn't it the case that a Fortran programmer who wants large arrays doesn't want many of them? It is inconceivable that anyone wants (say) 100 arrays at 20Gb each ...

Isn't it also the case that the only part of Windows 64bit that is truly 64bit is the heap, and we use the heap for allocatable arrays? Hence, a general purpose 64bit capability would be useless in any case, as the static area is the same size in 32 and 64 bit Windows.

Surely, therefore, gaining a very large array capability isn't a matter of making the whole back end 64 bit, but of adding the capability to create and use a small number of INTEGER*8 addressable arrays that have to be ALLOCATE-able. My enquiries lead me to suspect that most users clamouring for 64 bit capability really only want one such array!

Microsoft Fortran used to have a limit on array sizes that was overcome initially by declaring arrays as [HUGE] - they weren't all that huge, my recollection is that it permitted them to be more than about 32k.

My suggestion therefore is that you have a think about permitting a programmer to declare a small number of arrays as 'Silverfrost Huge', which would require INTEGER*8 addressing.

As for me, my overarching requirement is simply that 32-bit code runs in Windows 64bit.

Eddie

Thanks for the suggestion Eddie. At the moment I do not know how to do that. How do you import/export from/to a 64bit address using 32bit assembler? If I do it via a pipe to a 64bit DLL then that would be messy and very slow.

I fully agree with Dan!

It becomes necessary to have a 64-bit compiler of FTN95 just before adding new features like F200x. The customers ask for software products running as a 64-bit application although nothing inside of the software will really need 64 bit. They just want to see there software will be installed in C:/Windows/Program Files and in C:/Windows/Program Files (x86). So it might be just an argument for selling the product as a 'modern' software.

You have to go with the development and not against the development. It is no good argument to say even old DOS applications are running in a DOS box under Windows7-64 bit.

We are not developing our software for scientific purposes, we develop for our customers!

Regards,

Detlef

Hi Paul,

You put me on a spot where my ignorance shows!

I'll think about it and respond when I get back from a week's travels.

Parsing the code would be helped if you had an explicit ALLOCATE[HUGE] (or some such) rather than trying to work out from context whether or not 64bit addressing was required.

I also imagine that programmers don't want to ALLOCATE and DEALLOCATE >2Gb arrays terribly often, so it doesn't matter if this operation is comparatively slow. Isn't this just a matter of carving out a block of the heap and telling Windows 'Keep off, this is mine'. Maybe that could be done in your 64 bit DLL.

My mental picture of how the 32 bit program would talk to its 64 bit memory pool is rather like disk caching or virtual memory operation (except that the 'disk' is the 64 bit memory area). If the user runs through his huge array sequentially when operating on it, and the cache is big enough, the cache misses should be comparatively few in number, and then again, cache reloading could be run through your 64 bit DLL.

Presumably a cache could be around a gigabyte or so, using up a big proportion of the 32bit heap.

In my hazy memory is a recollection that virtual memory operations were a part of FTN77 with DBOS, so maybe the niceties of this have already been worked out.

Even under Windows 32bit, there were 'virtual disk' or 'ramdisk' programs that could use RAM beyond 4Gb as if they were hard disks. I remember suggesting to several people that this was a way forward - their programs written to use disk-based solutions would speed up significantly if they used 'ramdisks' instead of physical disks, but this is a solution that software developers who write software for others cannot use, as their software has to run on whatever machine the final user has at his disposal.

Regards

Eddie