|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Feb 08, 2016 10:29 am Post subject: A cautionary tale. |
|
|
I have a bit of software that I used to use a lot but now use more rarely. From the change log in appears I got it working in November 1974. It survived the transition from cards to paper tape back again, it’s been on dozens of systems, and because it is graphics based it has driven all manner of plotters via all manner of graphics systems. I needed it last week, and dug it out. The last time I compiled it was in 1999, then with FTN77.
Its on-screen graphics appear in a %dw box, and back then it was safe to assume that the monitor aspect ratio was 4:3. That is no longer a sensible assumption, and the graphics were coming out distorted. So I recompiled it all with FTN95, and that was enough to stop it working. The error message related to ‘loss of precision’. I tried all manner of things including compiling with -intl and -dreal switches, and in the end (because the error arose in an extremely short subroutine) commented out the subroutine calls one by one. I’d had a look in the .INS files and couldn’t see that I’d mismanaged any types, and eventually I tracked down the problem to this statement (not that it required much searching, as the subroutine indicated by the error message contains only 3 executable statements!):
Code: | L = MoveToEx (IHDC,IX1,IY1,0) |
I’d already tried making the zero 0L, but eventually succeeded with:
Code: | N = 0
L = MoveToEx (IHDC,IX1,IY1,N) |
I’d also examined whether or not the issue was the default to VGA colours changing to RGB colours, but it wasn’t that.
So what is the compiler command that makes all explicitly given INTEGER constants INTEGER*4? |
|
Back to top |
|
|
Wilfried Linder
Joined: 14 Nov 2007 Posts: 314 Location: Düsseldorf, Germany
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Feb 08, 2016 2:48 pm Post subject: |
|
|
Hi Wilfried,
I tried that, but it didn't work, which confused me as I thought it should work.
I went through the 12 files and put it in an OPTIONS (INTL) directive, then when that didn't work I specified it on the compilation command line, all to no avail.
I hated using %dw, and it is only the fact that it was an early program before I realised that %gr was the way to go, that has left me with a MoveToEx in one routine in one program!
I just mentioned it out of interest. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Tue Feb 09, 2016 10:52 am Post subject: |
|
|
/INTL is the default assuming that FTN95 has not been configured differently via /CONFIG. Similarly all literal integers are INTEGER*4 by default.
I don't recall what MoveToEx expects. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Feb 09, 2016 11:20 am Post subject: |
|
|
MoveToEx expects INTEGER*4 - I looked in the INS file.
I can't remember the settings of FTN77 after all this time, and FTN95 is configured how it set itself up on installation, so FTN77 was probably the same.
I was surprised that my efforts using OPTIONS and 0L seemed to have no effect, that's all, but it was instantly fixed by passing the 0 to N, and using that in the subroutine call. If I need that old program again I'll convert from %dw to %gr, or maybe now the aspect ratio is fixed I'll leave well alone.
It certainly isn't something that I think needs investigation, and it only worried me in the senses that (a) I doubted my understanding for a while (my understanding being what you wrote), and (b) for an equal length of time I imagined that I would be converting to %gr then and there!
Eddie |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Feb 09, 2016 11:37 am Post subject: |
|
|
I have always used /intl and /logl in my ftn95.cfg, which makes me think that the default for F77 was /ints and /logs.
I do remember that a lot of program development I did in 70's was using INTEGER*2 and have some recollection that that was the default for F77, but it was a long time ago !!
There were also a lot of I*2 variables in the library routines. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Feb 09, 2016 3:15 pm Post subject: |
|
|
Sure, but which FTN77 are you talking about? FTN77/386, /486 with DBOS, DBOS and Clearwin, or FTN77 with its colours nailed firmly to the Windows mast?
By 1999, FTN95 was 32-bit Windows only, if I recall. I used INTEGER*2 a lot with MS Fortran, and even struggled with REAL*4, which although by dint of careful coding still produced acceptable answers, but they were different - subtly - if one used the software emulation for the coprocessor or the coprocessor itself. The math libraries were subtly different.
The old stuff is archaeology, and I only mentioned it because the old EXE ran fine today using its Salflibc.dll, and equally well with an up to date Salflibc. It compiled fine with FTN95, but had a runtime error.
Dare I experiment with even older programs, unused for even longer? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Tue Feb 09, 2016 5:29 pm Post subject: |
|
|
The final argument for MoveToEx is a returned pointer that can be NULL so one can use CORE4(0) for 32 bit. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Feb 09, 2016 5:42 pm Post subject: |
|
|
Paul, thanks for looking it up. I imagine that MoveToEx will never cross my path again. |
|
Back to top |
|
|
|
|
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
|