Adriaan van Os wrote:
Gale Paeper wrote:
In looking at the actual generated PPC assembly code for the trash procedure in nonloc2goto.pas and the trash function in nonloc4goto.pas, both end up using an 80 byte stack frame.
I'm at a loss to explain why the stack frame is so large. There is nothing in the assembly code for those two routines which would require that large of a stack frame but that's what the compiler generates.
Thanks for your comments to my previous post. I am experimenting a bit now and I think it has something to do with the --inline-functions flag, that is turned on by -O3. Without the --inline-functions flag, there is no stack overflow.
I wouldn't rely up the lack of a OS stack overflow report as indicative of a small stack size. In one -O3 execution test I ran with 10000 levels of recursion, I got no problems reported; however, the trash stack frame size was still 80 bytes as the assembly code showed.
I also tried varying optimization levels from no optimatization, -O, -O2, and -O3 and all stack frame sizes for thr trash procedure and function was 80 bytes.
I also saw a range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination indicating something was stomping on memory being referenced by the terminating code. (This was seen in some follow up testing with a reduced recursion level to keep the stack in the 512K bounds. With or without Frank's writeln suggestion, I got the expected Pascal output - the errors showed up during termination code execution after the main program code had finished ececuting.) But that may be just bugs in the older gpc version 20030830 I'm testing with and may have been fixed in the new gpc version 20040516.
To see whether it is a Pascal front end issue or a generic PPC backend issue, I wrote C equivalents for those to routines.
What are the specs of the C compiler or did you use gpc as the C compiler driver ?
As I indicated in my previous posting , I used GPC as the compiler driver for both Pascal and C tests. As a follow up, I also looked at the assembly code produced by Apple's gcc compiler for the C code. The gcc specs are:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
I didn't see any difference between Apple's gcc generated assembly code and the GPC driven C compiler generated assembly code. For both compilers' generated assembly code, the trash procedure was tail call optimized with no stack frame and the trash function had a stack frame size of 80 bytes.
Gale Paeper gpaeper@empirenet.com