Data stack cleared after typo

[barewires]

Running 2.2.19 (many thanks) on a C0135

300 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ____ 310 0 20 0 30 3 15 3 17 0 10 3 10 56 78 12 34 _ 4 _ Vx_4 ok .s 1234 5678 <sp ok ..s ..s? .s <sp ok 300 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ____ 310 0 0 0 0 0 20 0 30 3 19 3 1B 0 10 3 10 _ 0 _ ok Is this a bug or a feature?

[TG9541]

Hi barewires, that's a feature, not a bug :-) Clearing all stacks is one of the tasks of QUIT, the outer Forth interpreter loop:

From Starting Forth:

QUIT, in simplified form, looks like this:

: QUIT  BEGIN  (clear return stack)
               (accept input)
               INTERPRET
               ." ok " CR
               AGAIN ; 

To be honest, when I started integrating STM8 eForth with e4thcom I had a beef with that "feature": the old RAMMARK relied on storing CP, last, and CONTEXT on the stack. A lost cause when using e4thcom #require which relies on an "error" to find out if a word needs to be loaded.

[larsbrinkhoff]

Per Standard Forth, and your example from Starting Forth, QUIT should not clear the data stack. Just the return stack.

[larsbrinkhoff]

However, entering a typo may call ABORT, which should clear both stacks.

[TG9541]

Hi Lars, thanks for your comment!

You're certainly right, but at some point in the linked Starting Forth section you'll find this definition:

QUIT | ( -- )
-- | --
Clears all stacks and returns control to the terminal. No message is given.

Do you know of a Forth that doesn't call ABORT? If so, what's the usual way a user clears all stacks?

[larsbrinkhoff]

Ok, maybe Starting Forth is based on an older version of Forth, or there was a misunderstanding. Here are the definitions of QUIT and ABORT in Forth94 (the 1983 and 2012 standards are much the same):

http://lars.nocrew.org/dpans/dpans6.htm#6.1.2050
http://lars.nocrew.org/dpans/dpans6.htm#6.1.0670

Calling ABORT would be the normal way to deal with an error. QUIT is a softer way to exit an application and enter interactive mode.

There's no standard word for clearing the stacks without raising an error. Some like to call it CLEAR or EMPTY.

[TG9541]

I guess that the point is that an error normally is communicated by ABORT (which resets the data stack), and the interpreter is then restarted by QUIT which resets the return stack (e.g. to prevent calling the interpreter).

[larsbrinkhoff]

Right!

[barewires]

Interesting discussion, I just found it odd that my 'valuable' data got obliterated so easily. On another note, looking at the stack behaviour with all that data movement, I think that a circular buffer would be far more efficient as a stack. Just a thought.

[TG9541]

Maybe I'll introduce a feature to deal with keeping stack data (e.g. a word that restores the stack pointer, or one to dump past stack data). What do you think? Circular Buffer: I guess that Chuck Moore would agree -> MachineForth

[larsbrinkhoff]

Marcel Hendrix has now updated the description of QUIT in his online version of Starting Forth:
http://home.iae.nl/users/mhx/sf9/sf9.html
Apparently, the error was also in the original book edition.

I have also contacted Forth Inc about their copy.

[barewires]

I’m All Right, Jack, Keep Your Hands Off My Stack, or Keep Your Hands Off My Circular Buffer! A little Pink Floyd - Money - from 1973 never hurt when I built my Altair in 1975. The lyrics are old Brit and are Lost In Translation (a great movie) https://www.youtube.com/watch?v=JkhX5W7JoWI

[VK6TT]

This is sounding more like a solution looking for a problem the longer the discussion goes on. I never write code that assumes quit or abort is called. The only time I call quit or abort is inadvertently when I'm bashing away on the keyboard and fat finger something.

Since I find this implementation of forth so much fun to play around with I don't rate compliance with someone else's standard highly. In fact, I don't mind if it is non-standard as long as I understand how to use it. What does matter to me is documentation on the words supplied and correction of bugs that cause a crash or unexpected results. And of course help when I can't nut something out grin.

So from my perspective I'd rather see you leave it alone so you stay fresh and motivated when something worthy of your time comes along.

Regards Richard

---

From: Thomas [mailto:notifications@github.com] Sent: Wednesday, 8 November 2017 9:58 PM To: TG9541/stm8ef Cc: Subscribed Subject: Re: [TG9541/stm8ef] Data stack cleared after typo (#108)

Maybe I'll introduce a feature to deal with keeping stack data (e.g. a word that restores the stack pointer, or one to dump past stack data). What do you think? Circular Buffer: I guess that Chuck Moore would agree -> MachineForth

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view https://github.com/TG9541/stm8ef/issues/108#issuecomment-342824960 it on GitHub, or mute https://github.com/notifications/unsubscribe-auth/AT7yaz8RAH09_HoXmNUEJ2kcm w6CNZePks5s0bN7gaJpZM4QUmo3 the thread. https://github.com/notifications/beacon/AT7ya35SnFhAcgIySgVzjBpwpwmUTx3kks5 s0bN7gaJpZM4QUmo3.gif

[larsbrinkhoff]

I checked the kernel, and QUIT and ABORT already comply by the standard. So there's nothing to fix unless there's a need for a feature to go beoynd the standard.

[TG9541]

I'll close the issue now. Thanks for the discussion and for the comments, and especially to Lars for taking asking Marcel Hendrix to fix "reference literature"!

I'll look into providing some kind of "stack recovery" after abort (most likely a word that can be loaded at runtime, but obviously before you need it ;-) ).