Click for: WEBPAGE INDEX
web 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!
|