CPU OVERLOAD

I have been using the Personal Edition of FTN95 and have found it to work perfectly on a number of programs, each with 3000+ lines of code. However, even on a minimum number of lines of code, the CPU is heavily loaded, even when no program functions are in progress (i.e., waiting for keyboard input). The CPU is an Intel Core-2 6600 at 2.4 GHz with 2 Gigabytes of RAM. The programs respond the same way on my laptop computer, but it cannot support the load indefinitely without overheating the CPU. One is running MS-Vista and the other one is running MS-XP.

The overload only occurs when a window is open. The following code is used to open the window. WINAPP INCLUDE <WINDOWS.INS>

  NEWFONT=CREATEFONT(LFHEIGHT,LFWIDTH,LFESCAPEMENT,
 +  LFORIENTATION,LFWEIGHT,LFITALIC,LFUNDERLINE,
 +  LFSTRIKEOUT,LFCHARSET,LFOUTPRECISION,
 +  LFCLIPPRECISION,LFQUALITY,LFPITCHANDFAMILY,LFFACENAME)

C/////DEFAULT FONT SET AND WINDOW SIZE SET CALL SET_DEFAULT_FONT@(NEWFONT) XSIZE=CLEARWIN_INFO@('SCREEN_WIDTH') YSIZE=CLEARWIN_INFO@('SCREEN_DEPTH') XPOS=0 YPOS=0 NWIN=CREATE_WINDOW@( + 'XXXXXOOOOOXXXXXOOOOOXXX', + XPOS,YPOS,XSIZE,YSIZE) CALL SET_DEFAULT_WINDOW@(NWIN)

CREATE_WINDOW@ and similar routines are obsolete. It is recommended that you use WINIO@ instead.

If you want to post a small but complete working program then I could look at it but it would be better if you changed to WINIO@.

Enclosed is a simple test program as you requested. It runs perfectly, but the CPU loading is more than 50 percent. As a comparison, Microsoft Word 2007 only creates 1 to 2 percent CPU loading.

It would be great if there were a simple fix, since it is so easy to convert existing 3000+ line programs for FTN95, especially when there is a large amount of keyboard interaction.

C/////THIS IS A DUMMY TEST PROGRAM TO TEST CPU LOADING C/////CPU LOAD IS MORE THAN 50 PERCENT AT 'READ' 4 LINES FROM BOTTOM WINAPP INCLUDE <WINDOWS.INS> INTEGER XSIZE,YSIZE,XPOS,YPOS INTEGER NEWFONT,LFHEIGHT,LFWIDTH,LFESCAPEMENT, + LFORIENTATION,LFWEIGHT,LFITALIC,LFUNDERLINE, + LFSTRIKEOUT,LFCHARSET,LFOUTPRECISION, + LFCLIPPRECISION,LFQUALITY,LFPITCHANDFAMILY CHARACTER LFFACENAME80,HOLD1 C/////VALUES ASSIGNED TO FONT PARAMETERS LFHEIGHT=32 LFWIDTH=14 LFESCAPEMENT=0 LFORIENTATION=0 LFWEIGHT=700 LFITALIC=0 LFUNDERLINE=0 LFSTRIKEOUT=0 LFCHARSET=0 LFOUTPRECISION=1 LFCLIPPRECISION=2 LFQUALITY=2 LFPITCHANDFAMILY=34 LFFACENAME='COURIER NEW' C/////NEW FONT CREATED FOR FORMAT WINDOW NEWFONT=CREATEFONT(LFHEIGHT,LFWIDTH,LFESCAPEMENT, + LFORIENTATION,LFWEIGHT,LFITALIC,LFUNDERLINE, + LFSTRIKEOUT,LFCHARSET,LFOUTPRECISION, + LFCLIPPRECISION,LFQUALITY,LFPITCHANDFAMILY,LFFACENAME) C/////DEFAULT FONT SET AND WINDOW SIZE SET CALL SET_DEFAULT_FONT@(NEWFONT) XSIZE=CLEARWIN_INFO@('SCREEN_WIDTH') YSIZE=CLEARWIN_INFO@('SCREEN_DEPTH') XPOS=0 YPOS=0 NWIN=CREATE_WINDOW@(

• 'THIS IS A TEST PROGRAM',
• XPOS,YPOS,XSIZE,YSIZE) CALL SET_DEFAULT_WINDOW@(NWIN) CALL CLEAR_WINDOW@(NWIN) WRITE(,'(''THIS IS A TEST'')') READ(,'(A1)')HOLD CALL DESTROY_WINDOW@(NWIN) STOP END

OK, but have you tried the following approach...

WINAPP
READ*,x
PRINT*,x
END

I have tried your program and I can see the problem that you describe.

My simple program also exhibits the same problem.

We will investigate. At this point I do not know if it will be easy to fix.

The good news is that, if you run both your program and mine simultaneously then they each use about half of the CPU so the programs are not blocking other programs from taking a share of the CPU.

Paul,

The problem that Baldeagle describes has nothing to do with a window being open. It has always been the case with FTN95, FTN77 that whilst the program is waiting for user input via a fortran READ statement that task manager shows the application has loaded the CPU up to 99%. A non-windows DOS program does the same high CPU loading.

Baldeagle,

If you use winio@ with %rd, %rf , %rs to enter integer, real and character data then you will see that the CPU loading of the application will be listed as 0% by task manager.

Of course the fortran READ statement is an original part of the language created long before multi-tasking had even been dreamt of.

I hope this helps.

regards, John

The issue wih the READ statement, which JohnHorspool described, is the cause of the CPU loading. Using winio@ for input reduces the CPU loading to a negligile level. It would have been convenient to leave the large number of READ statements in place, but this is a workable alternative.

Thanks for the help.