Turbo Pascal 4.0 - Stack Overflow

[TheKingfish]

I’m a long time fan/user but am confronted with the above Fatal Error after steadily increasing a particular real array over many years [now at 1..800]. My stack size is seemingly set at maximum {$M 65520, 0, 655360}, and I just initiated the coprocessor option {$N+} switching from a Real to a Single data type. The latter seemed to have no effect. I could restructure my Global declarations or turn that Real/Single into an Integer, but that’s a lot of patch work for me downstream. The hard-to-read manual has never provided many good tips in this area. Any thoughts? Thanks.

[WingedPanther]

Umm... Turbo Pascal 5.5 was released 20 years ago. Any reason you're still on 4.0?

[TheKingfish]

I stayed with 4.0 for convenience more than anything, not really aware of subsequent DOS based product. At that time the pull-down menus and mouse were collectively a big improvement over what I had. I was also cognizant of Windows product, but chose not to go through the transition. I have no knowledge of 5.5. Would you expect it to relieve my capacity issues? Overall worth my while to switch?

[WingedPanther]

The biggest issue you are facing right now is the limitations of a DOS-based solution. I have no idea if 5.5 will help or not. In particular, if you are using MS-DOS from the 80's, then you will have LOTS of OS-imposed limits that are hard to work around. FreeDOS, which supports modern hardware, and DOSbox, which emulates DOS under Windows and Linux, may help you avoid some of those issues.

Ultimately, you are dealing with a system where the operating system imposed a limit of 640K on memory programs could use. This is a very real limitation, and it took a LOT of trickery to get around that barrier.

[TheKingfish]

Thanks for your continued input. Your insight on the DOS relationship to my issue was helpful; something I had not considered. Some added information on my OS set up, which provides a piece of the puzzle. I operate with DOS 4.10 (linked to Win98), which I have in a separate box used exclusively for programming. Given the later version I’m using, do you suppose that absolves the OS and puts my capacity issue onto Turbo 4.0? I have a feeling that is so, based on some data files that run and some just-slightly larger ones that don’t; it feels like I’m teetering on the software’s capacity edge. For the software remedy, what I don’t know is the technical capacity of each (4.0 vs. 5.5) which would provide direction. They might be identical, which offers no solution. I will attempt to research that, but ask you again to share your overall thoughts. Thanks.

[WingedPanther]

I'm not sure what you mean by DOS 4.10 being "linked" to Win98. You are using one or the other at a time. While in DOS 4.10, you are limited by all its restrictions. While in Win98, you are still trying to use a compiler that respects the limitations of DOS, even if Win98 doesn't have those same limitations.

I think what you need to do is rethink how you're processing your data. Instead of trying to store ALL of it in memory at once, think about ways to have only chunks of it in memory at a time.

[Firebird_38]

May I respectfully suggest you dump your old stuff and go with new?
You can easily switch to lazarus for free. That's a non-issue. Using a VCL (visual component library) takes about a day to get used to. Also, newer OS's still support the console mode, also for 32 bit programs.

You should know that at that point it becomes very hard to outstrip your capacity.

But before you dismiss me as a non-help, may I suggest that you shouldn't be storing large stuff on the stack? I'm guessing we're talking a local variable:

procedure MyProc;
var MyBigStuff:array[0..800] of single; //This goes on your stack, all of it. Use the heap!
begin
 ...
 //access items like this
 MyBigStuff[0]=0.1;
 ...
end;

That's bad. Instead do this:

procedure MyProc;
type
  //First we define our large array as a type
  TMyBigArray=array[0..800] of Single; //max count is 65520 div SizeOf(Single) in DOS!
  //Then we go ahead and define a pointer type to that type
  PMyBigArray=^TMyBigArray;
//You can define these somewhere else if you use them elsewhere...
var MyBigStuff:PMyBigArray; //this is now a pointer (only 4 bytes on the stack!!)
begin
 //FIRST reserve the memory:
 New(MyBigStuff); //This  now creates your data on the heap. 1 call only.
 //Also consider "GetMem", if you want to allocate more or less than the 800 defined:
 //Like: GetMem(MyBigStuff,SizeOf(Single)*HowEverMany);
 //Then do stuff with it:
 ...
 //the main difference is that you have to de-ref your pointer now to use... :(
 //Like this:
 MyBigStuff^[0]=0.1;
 //Modern pascal automatically does this for you, but not TP4.

 ...
 //Then, when done, free it. Make sure it gets freed!!!
 Dispose(MyBigStuff); //This is only 1 call, lots of comments... :)
 //if you used GetMem, you must use freemem (with the exact same size as getmem!)
 //Like this: FreeMem(MyBigStuff,SizeOf(Single)*HowEverMany);
end;

I hope this helps. To "dereference" everyewhere, just use search/replace:


Select your procedure or function, then click replace. (Or is it type? I forget in TP4)
Find: MyBigStuff
Replace: MyBigStuff^
Use "selected only" for your search range. You can check "Whole words only" if you like.
Click "Replace All"

[Firebird_38]

Also, Lazarus is free and costs no money. Plus you don't have to pay for it. As a bonus, it compiles on other platforms. You can now run your TP4 stuff on Mac! And Linux!