Group: comp.lang.forth · Group Profile
Author: Jonah ThomasJonah Thomas Date: Aug 6, 2008 07:12
> John Passaniti JapanIsShinto.com> wrote:>> Andrew Haley wrote:
>>> Forth Inc have always had a zero "guard cell" beneath the bottom
>>> of the stack. Â It's a really good idea.
>>
>> Why? Â I would think it would potentially mask problems and make
>> testing more difficult. Â If I try to pop off an empty stack, I want
>> to be explicitly told about it-- at least during development
>> (minority architectures that have circular stacks notwithstanding).
>
> On a debug platform I could see this as useful. My personal approach
> will be a decompile or dump window which halts execution, and displays
> either stack, current execution point, or any selected memory location
> contained in any dump.
>
> Fields would be hex value, word name of hex value, word at indirect
> pointer of value, and string of pointed value. A TRAP word to switch
> on such a debug view would work best.
>
> I know people like rock solid stability, but it costs in code size and
> speed, which is not the things you want to sacrifice in certain uses
> of forth.
Yes. It's pretty common for Forths to check stack depth before or after
the parser looks up a word and executes it. Or at the start or end of a
line of input. The cost is tiny at that point compared to the cost
you're already getting by interpreting. Then you don't find out where
the problem was internally, but you know the problem came wrt what you
typed.
It does make sense to have a special debug mode or a whole debug
compiler (that should be 100%% compatible with the Forth system you'll
actually use). I first programmed in Forth on a system that couldn't
spare that luxury and I didn't miss it. I designed several debug
environments and then didn't use them. I gave them to my students and
they didn't use them either. I'm not sure why not.
| 
