Forum unknown
· Programming
Stack size calc
17 messages in this thread
Not really keith… there are already stacks in the Amiga that grow upward.
They are the BCPL stacks, and is one of the reasons for a number of nasty
bugs that have had to be stomped in the OS. If they ALL grew one direction,
it wouldn't matter a bit which way they grew, as they always overflow onto
important data. 🙂
Hmmm… what I'm really getting at smacks of your 'dream compiler'… I'm
thinking of this stack manager _allocater_ that _allocates_ more stack for
you (up to the limit of mem) "as you need it", and thus would grow 'up'.
If it grew 'down' then that kinda' implies that you set some top limit and
eventually (much more quickly) hit 'bottom' (ie. the current state of
affairs).
Nah – the problem is, there are _multiple_ stacks – one for each process,
and at least one for the system mangement utilities. Growing up is no
better than growing down, because of that. For that matter, if there was
only one stack, you could have it grow down and allocate more jsut as
easily as the other way. –Ben–
Nah – the problem is, there are _multiple_ stacks – one for each process,
and at least one for the system mangement utilities. Growing up is no
better than growing down, because of that. For that matter, if there was
only one stack, you could have it grow down and allocate more jsut as
easily as the other way. –Ben–
Keith, unless you have some sort of MMU you're solution is un-implementable.
You also have to worry about where the Allocate() is going to find the
memory. Usually these are the items which will collide in a single-tasking
system. While it is possible to have one (1) such 'restricted only by
memory/addressing considerations' memory region in a system, it is difficult
to have many.
Keith, unless you have some sort of MMU you're solution is un-implementable.
You also have to worry about where the Allocate() is going to find the
memory. Usually these are the items which will collide in a single-tasking
system. While it is possible to have one (1) such 'restricted only by
memory/addressing considerations' memory region in a system, it is difficult
to have many.
Hmmm… what I'm really getting at smacks of your 'dream compiler'… I'm
thinking of this stack manager _allocater_ that _allocates_ more stack for
you (up to the limit of mem) "as you need it", and thus would grow 'up'.
If it grew 'down' then that kinda' implies that you set some top limit and
eventually (much more quickly) hit 'bottom' (ie. the current state of
affairs).
If the upwards growing data stacks in BCPL were a problem, it was only
because of illiterate C programmers not understanding that there are other
possibilities than were apparent to the kids who invented the C language. I
find it ludicrous that in C the expression:
(a=getc(), b=getc(), c=getc())
does one thing if used in a regular statement, and may do another if used
as an argument list to a function. This is an example of not thinking
things through and one of Cs bigger mistakes. I note that it is not
addressed in the ANSI standard either, there is too much poor C written
already which must still be compilable with the new compilers.
I would say it has far more to do with illiterate BCPL programmers not
understanding the 68000, or are you suggesting that C and assembly etc.,
language stacks should be growing upwards also???
func(a, b, c) is a problem on upward or downward stacks, at least as far as
evaluation order is concerned, unless I miss the point here.
sdb
I believe I've stated before my preferences for upwards growing stacks. As
for HLL programmers 'understanding' the machine, that is completely
irrelevant. HLLs are SUPPOSED to make understanding the machine
unnecessary and irrelevant. As for func(a, b, c) being a problem, I point
out that C was the FIRST and to my knowledge, the ONLY language which
allowed for evaluation in some order other than left to right. If APL
allows is (I don't remember any function calls in the APL I've used), I
apologize in advance.
I wasn't aware of your preference for upward growing stacks and while HLL
langdo eliminate the need to 'understand the machine' they don't eliminate
the need for efficient implementation of HLL's, which on the 68xxx means
downwards growning stacks.
I agree that func(a, b, c) eval order is a problem, I also think it should
have been specified to be from left to right, but I still don't see how
this is related to upward/downward stacks. Sorry for not being clearer
about this. sdb
As I gather, the ONLY reason that C 'allows' for right to left evaluation
is because Ritchie INSISTED that the calling sequence be: push, push,
push, call. On a downards growing stack (assuming that you want the
arguments to appear as a structure of similar composition in memory) that
means to evaluate the arguments from right to left.
***NOTE*** this is SAME person who INSISTS that the epression:
c = *a++ + *a++
is allowed to be equivalent to:
c = *a+*a; a+=2;
in that the multiple ++ operators can be 'optimized' into one operation.
If you have such persons designing lanugages, it's no wonder there are
ambiguities and silliness. <pause in editorial comment>
As I gather, the ONLY reason that C 'allows' for right to left evaluation
is because Ritchie INSISTED that the calling sequence be: push, push,
push, call. On a downards growing stack (assuming that you want the
arguments to appear as a structure of similar composition in memory) that
means to evaluate the arguments from right to left.
***NOTE*** this is SAME person who INSISTS that the epression:
c = *a++ + *a++
is allowed to be equivalent to:
c = *a+*a; a+=2;
in that the multiple ++ operators can be 'optimized' into one operation.
If you have such persons designing lanugages, it's no wonder there are
ambiguities and silliness. <pause in editorial comment>
I wasn't aware of your preference for upward growing stacks and while HLL
langdo eliminate the need to 'understand the machine' they don't eliminate
the need for efficient implementation of HLL's, which on the 68xxx means
downwards growning stacks.
I agree that func(a, b, c) eval order is a problem, I also think it should
have been specified to be from left to right, but I still don't see how
this is related to upward/downward stacks. Sorry for not being clearer
about this. sdb
I believe I've stated before my preferences for upwards growing stacks. As
for HLL programmers 'understanding' the machine, that is completely
irrelevant. HLLs are SUPPOSED to make understanding the machine
unnecessary and irrelevant. As for func(a, b, c) being a problem, I point
out that C was the FIRST and to my knowledge, the ONLY language which
allowed for evaluation in some order other than left to right. If APL
allows is (I don't remember any function calls in the APL I've used), I
apologize in advance.
I would say it has far more to do with illiterate BCPL programmers not
understanding the 68000, or are you suggesting that C and assembly etc.,
language stacks should be growing upwards also???
func(a, b, c) is a problem on upward or downward stacks, at least as far as
evaluation order is concerned, unless I miss the point here.
sdb
If the upwards growing data stacks in BCPL were a problem, it was only
because of illiterate C programmers not understanding that there are other
possibilities than were apparent to the kids who invented the C language. I
find it ludicrous that in C the expression:
(a=getc(), b=getc(), c=getc())
does one thing if used in a regular statement, and may do another if used
as an argument list to a function. This is an example of not thinking
things through and one of Cs bigger mistakes. I note that it is not
addressed in the ANSI standard either, there is too much poor C written
already which must still be compilable with the new compilers.