<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Fri, 16 Dec 2011 20:55:56 +0100
From   : kortink@... (John Kortink)
Subject: 32016 + 32082

On Fri, 16 Dec 2011 17:27:59 +0000 (WET), Peter Coghlan
<BBCMICRO@...> wrote:

>[...]
>
>>So, the /main/ reason for saving the 6502 stack on every PROC/FN
>>(besides a couple of other things) is basically the fact that the
>>formal parameter addresses are on it while the actual parameters
>>are being evaluated (which can cause further calls to PROC/FNs).
>>And, in contrast to the other stuff, the size of that is, to some
>>extent, unbound. You could probably crash BASIC in a single call
>>if you gave the relevant PROC or FN enough parameters.
>>
>
>This is quite different to saying that it doesn't do this to
>avoid ordinary stack overflow due to deeply nested PROC/FN calls
>but primarily for performance reasons.

No, it isn't. BASIC doesn't save and restore the 6502 stack to
avoid the overflow per se. It could do that by simply using the
BASIC stack for everything. But that is slow. Hence using the
6502 stack for some of the data (and saving/restoring it) is an
optimization.

>(I don't know where the addresses of formal parameters are when the
>actual parameters are being evaluated but Mark Plumbley seem to
>say the 6502 stack has already been saved on the BASIC stack and
>then cleared by the time any processing of arguments is done.)

Of course it is. Because that's the most logical place for it.


John Kortink

-- 

Email    : kortink@...         
Homepage : http://www.inter.nl.net/users/J.Kortink
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>