forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

A cautionary tale.

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Feb 08, 2016 10:29 am    Post subject: A cautionary tale. Reply with quote

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
View user's profile Send private message
Wilfried Linder



Joined: 14 Nov 2007
Posts: 314
Location: Düsseldorf, Germany

PostPosted: Mon Feb 08, 2016 12:40 pm    Post subject: Reply with quote

Eddie,

I think that /intl is the compiler option you asked for:

http://www.silverfrost.com/ftn95-help/options/_intl_and_ints.aspx
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Feb 08, 2016 2:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Feb 09, 2016 10:52 am    Post subject: Reply with quote

/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
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Tue Feb 09, 2016 11:20 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Feb 09, 2016 11:37 am    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Tue Feb 09, 2016 3:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Feb 09, 2016 5:29 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Tue Feb 09, 2016 5:42 pm    Post subject: Reply with quote

Paul, thanks for looking it up. I imagine that MoveToEx will never cross my path again.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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