Hello!Anyone knows something about stack and heap size in PureC? What are the standard values and what are the safest settings?How can I determine if the settings are too low or not optimal? I've read on the net that these settings are system dependant, so how it relates to atari st/falcon TOS ?

saulot wrote:Anyone knows something about stack and heap size in PureC? What are the standard values and what are the safest settings?How can I determine if the settings are too low or not optimal? I've read on the net that these settings are system dependant, so how it relates to atari st/falcon TOS ?

The default stack size is 4 kB.If the stack size is to low the program might crash.The heap size is all free memory that isn't used by the stack and the program. The OS will tell you the size of the heap with Malloc(-1). The heap size can not be set (you can enter a value in the linker but it is ignored).

If you do deep recursive function calls with lots of data in the stack you have to calculate the needed stack size and enter the calculated value with a nice safety margin.

If you want to know the stack usage write a small assembly routine that performs this function:max_stack=max(start_stack-SP,max_stack);And call this function at the start of you recursive functions and print the value of max_stack when the program has finished running.

Nyh: thanks for the tips. So there this linker heap option is totally useless, it seems that the manual missed to mention this 'feature' completely . Is there something more (like list of known bugs somewhere)? I'm also curious about the last compiler version that was released (version 1.1 was the last one?)

saulot wrote:Is there something more (like list of known bugs somewhere)? I'm also curious about the last compiler version that was released (version 1.1 was the last one?)

AFAIK Pure C 1.1 is the most recent version.Pure C is very good but Pure C is not completely bug free. I once stumbled on a compiler error within a macro expansion of a function. I never took the time to find out what exactly goes wrong and why. That is the only real compiler bug I came across in all the time I have been using Pure C. That is almost 20 years if you count Turbo C too.

Variables allocated on the stack are stored directly to the memory and access to this memory is very fast, and it's allocation is dealt with when the program is compiled. When a function or a method calls another function which in turns calls another function etc., the execution of all those functions remains suspended until the very last function returns its value. The stack is always reserved in a LIFO order, the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack, freeing a block from the stack is nothing more than adjusting one pointer. More about.....Stack and Heap

Pure C is very good but Pure C is not completely bug free. I once stumbled on a compiler error within a macro expansion of a function. I never took the time to find out what exactly goes wrong and why. That is the only real compiler bug I came across in all the time I have been using Pure C. That is almost 20 years if you count Turbo C too.

I have noticed a strange stuff using Pure C for Rebirth (https://github.com/gibs75/demOS): when you use pointer arithmetics and using short* or long* instead of char*, the compiler sometimes generates calls to ldivs instead of asr which is very sub-optimal. I noticed that because the linker does not find ldivs when compiling without any standard libs