Click for: WEBPAGE INDEXweb page updated Tue 1st April 2003 306am Third attempt at this info! I've decided to remove the main stuff here. But I've left the generic comments about stacks in as they may be of interest. Nothing to do with GS8 any more. I began this page after making some unusual observations about the GS8 stacksize. However the same GS8 on one of my turboprint testers setup is behaving quite differently. So its probably just a gcc thing, as such I'm abandoning any further comments on this. I've left in the following generic ideas about stacks. 68k stacks grow downwards due to jsr f instruction being in c-notation: sp = sp - 4 ; *sp = pc ; pc = f ; That is, the sensible direction of stack growth is imposed on us by the h/w design. Programming note: In general it is a fact that local variables eat stack size. Even if the variables are register variables: on entry into a function non scratch registers need to be saved on the stack before use so they can be restored on function exit. Where other than on the stack can they be saved? So if you have lots of local variables eg int x[100] you could end up with huge stack wastage. This is one reason why in my own programs I always allocate arrays + structures etc dynamically, But when I look through source code, most people dont! By allocating dynamically, the memory is automatically cleared by using calloc, which doesnt happen with local variables. This reduces the garbage-contents problem. It is generally safer to use dynamically allocated memory. Stack memory turns into garbage on function exit. Dynamic programming is also more memory efficient and general. eg putting char fullname[200] could run into problems with a deeply situated file name on a huge hard disk. But by allocating the memory dynamically eg char *fullname; fullname=calloc(strlen(dirname)+strlen(name)+1,sizeof(char));strcpy( fullname , dirname ); strcat( fullname , "/" ) ; strcat(fullname , name ) ;you get code that is *always* correct and will allocate 2 bytes if that is wanted and 10 million bytes if that is required. Correct, tight and memory efficient with no guesswork. C memory allocation also tends to be *very* fast, faster than OS memory allocation as it is less general purpose. In my own experience I find dynamic programming is much cleaner. You get much fewer bugs, and it is more resistant to carelessness. Using local arrays + structures, (aggregate types) there is a good chance of running into the garbage-contents problem for different reasons. You would literally have to clear every field of a structure, or something equally horrendous to prevent garbage contents. As a matter of procedure I allocate all memory dynamically and have far fewer bugs + crashes as a result. eg of dynamic code: int *x; x=calloc( 100 , sizeof(int) ) ; instead of: int x[100]; Digressing completely!: I've never understood the point of 16 bit words. Sooner or later the 16 bits you set for something becomes too little. I can see the point of chars for strings and file bytes, but not for anything else. Use ints everywhere unless you have a good reason not to. eg for 24bit graphics one should use unsigned char * By using ints everywhere code becomes so much simpler. f( UBYTE *depth, unsigned int *width , char *pri ); :this is so horrible, just use: f( int *depth , int *width , int *pri ); Dont be a bit-miser, get a life. Sure a depth is always positive, but the set covered by UBYTE is a subset of that covered by int. Give yourself plenty of room, give yourself an int. And bits are so cheap these days!

Get a GoStats hit counter