btb@ncoast.UUCP (11/18/86)
Hello, Does anybody know of a good ratfor preprocessor... one that doesn't have some of the problems that our 3 have.... one that knows about f77? As an example, the ratfor for loop: for (i=1; i<=n; i = i + 1) translates into the horrible: i = 1 if (.not. (i .le. n)) goto (end of loop) ... i = i + 1 (goto if) rather than into the much more efficient: i = 1 if (i .gt. n) goto (end of loop) ... i = i + 1 (etc.) this may not seem like much, but I have benchmarked the above optimization change against the original code from a ratfor version of sieve, and it makes a factor of 2 difference... who knows how much more could be improved? (Incidentally, the ratfor fortran sieve ran 5 times slower than either the f77, or C sieve) We have a huge programming system all written in rat4... (Gipsy image processing software), running on a lil' 11/750... If you know of a "modern" rat4 we could get our hands on, I would appreciate it... I would also appreciate it if someone could tell me if the above code is necessary in some way that I am not thinking of? Thanks, -- Brad Banko ...!decvax!cwruecmp!ncoast!btb Cleveland, Ohio
rcb@rti-sel.UUCP (Random) (11/20/86)
At a place I used to work, we had some ratfor programs. A guy there modified the RatFor preprocessor (compiler) to detect the special case loop of for (i=x; i<y; i=i+z) This was converted in a VMS FORTRAN do loop instead of if's and goto's. This allowed the fortran compiler to detect that a loop was present and kick in loop optimizing code. I don't remember the numbers, but the improvement was significant. -- Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
btb@ncoast.UUCP (Brad Banko) (11/20/86)
Hello, Does anybody know of a good ratfor preprocessor... one that doesn't have some of the problems that our 3 have.... one that knows about f77? As an example, the ratfor for loop: for (i=1; i<=n; i = i + 1) translates into the horrible: i = 1 if (.not. (i .le. n)) goto (end of loop) ... i = i + 1 (goto if) (end of loop) rather than into the much more efficient: i = 1 if (i .gt. n) goto (end of loop) ... i = i + 1 (etc.) (end of loop) this may not seem like much, but I have benchmarked the above optimization change against the original code from a ratfor version of sieve, and it makes a factor of 2 difference... who knows how much more could be improved? (Incidentally, the ratfor fortran sieve ran 5 times slower than either the f77, or C sieve, so in other words, a ratfor preprocessor that knows about f77 could translate ratfor whiles and fors into f77 do whiles and dos... resulting in much quicker code.) We have a huge programming system all written in rat4... (Gipsy image processing software), running on a lil' 11/750... If you know of a "modern" rat4 we could get our hands on, I would appreciate it... I would also appreciate it if someone could tell me if the above code is necessary in some way that I am not thinking of? Also, if you, or someone you know has any experience with the Gipsy (General Image Processing System) software originally developed at Virginia Polytechnic Institute, please send me email... this package was originally developed to run on IBM systems, but has been ported (sort of) to VMS... We need help! Thanks, -- Brad Banko ...!decvax!cwruecmp!ncoast!btb Cleveland, Ohio
ken@rochester.ARPA (SKY) (11/21/86)
I guess you didn't get my mail, Brad. Changing the code generation for F77 is easy for both the yacc/C and portable Ratfor version. I can mail you the Ratfor version if you like. If you have only binaries, well that is another story. Ken
zben@umd5 (Ben Cranston) (11/24/86)
In article <1724@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes: > As an example, the ratfor for loop: > for (i=1; i<=n; i = i + 1) >translates into the horrible: > i = 1 > if (.not. (i .le. n)) goto (end of loop) > ... > i = i + 1 (goto if) > (end of loop) > rather than into the much more efficient: > i = 1 > if (i .gt. n) goto (end of loop) > ... > i = i + 1 (etc.) > (end of loop) Gosh, any Fortran compiler that doesn't produce the same or similar code for these two cases sure seems suspect - are you sure there isn't an "optimize" switch that you could invoke? -- umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS"