Hi George
 
On Saturday 18 February 2012, 9:56George Gwilt wrote:
 
> I use DEBUG 0 and 1 for the same reasons as you and have never had the fault 
> you mention.
 
> If you could send me, privately, a copy of your program I'll try to locate 
> the problem.
 
Thanks for your offer of help, this is really appreciated.  However, I believe 
I have solved the problem.  I tried moving the piece of code to near the 
beginning of the program, and this solved the puzzle.  My guess is that because 
my program is over 64k, the DEBUG mechanism could not cope, so that the fault 
is actually with Turbo.  DEBUG must be using unsigned integers, when it should 
be using floating point variables.  That is my guess.  The piece of code under 
question is:
 
22268 REMark DEBUG 1
22276 DEFine PROCedure how
22284 LOCal p, scan_rt
22292  CLS 2 : PRINT
22300  p = BASIC_L(56)
22308  REPeat scan_rt
22316   p = p + 24
22324   IF p > BASIC_L(60)-24 : EXIT scan_rt
22332   IF BASIC_W%(p+18)<>0
22340     PRINT "Call at ";BASIC_W%(p+18);" in ";
22348   ELSE
22356     PRINT "Stop at ";BASIC_W%(146);" in ";
22364   END IF
22372   IF BASIC_W%(p-12) > 0 : IF NOT COMPILED : LIST #1; BASIC_W%(p-12)
22380  END REPeat scan_rt
22388 END DEFine how
22396 REMark DEBUG 0

 
This piece was copied from the Turbo Toolkit Demos file, the original procedure 
name being How_COME.  My idea of using DEBUG was to try and save a little bit 
of code, because my program is so large.
 
 
Hi Malcolm
 
On Friday 17 February 2012, 21:35 Malcolm Cadman wrote:
 
> Also useful to use and declare integer values, wherever you can, at the start 
> of the BASIC program - which is "value%" rather than "value".
 
Yes, I agree.  There is a particular reason for this.  Suppose the compiled 
program stops somewhere with an out of range error.  The SuperBASIC version 
could then be run using the same input data, duplicate the error and stop at 
exactly same place.  The procedure "how" would then be run to discover the call 
hierarchies that got the program to that point.  Variable values could then be 
examined with the view to pin-point the cause of the error.  However, if using 
IMPLICIT% value, then the SuperBASIC version would be using floating point 
variables and the same error would not be produced and so would not stop at the 
same place.
 
Michael Bulford
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to