Control stack operations?

[SirWumpus]

The standard describes a control-stack Forth 200x draft 19-1 section 3.2.3.2 Control-flow stack. And there are two operations CS-ROLL and CS-PICK (with which CS-DUP, CS-SWAP, and CS-OVER can be implemented). However there is no CS-DROP and lots of other operations that might be used to define words, eg. HERE, +, -, etc. specify the data-stack.

If you have a separate control-stack from the data-stack I don't see how that might be used in most cases. It seems it would require duplicating a lot of words or how one would manage two separate stacks? This is more a theoretical question (my implementation uses the data-stack) but I'm curious as to the vision.

[MitchBradley]

The history: Wil Baden was adamant on the idea of expressing the control flow words in the form of a "basis" - a set of words that could be used to compose control structures. Prior to the ANSI standard, the status quo was a fixed "what you see is all you can get" set of control structures - IF .. ELSE .. THEN, BEGIN .. WHILE .. REPEAT, BEGIN .. UNTIL, BEGIN .. AGAIN. Many implementations were based on underlying primitives 0BRANCH and BRANCH , with perhaps an intermediate set of MARK and RESOLVE words to manage the branch offsets. With those primitives, it was possible to implement custom control structures, but it would have been difficult to standardize around them because of deep dependencies on implementation details. Wil realized that some of the existing words were very close to being primitive and, with a bit of care in the definition, could be used to compose additional control flow graphs, for example BEGIN .. WHILE .. WHILE .. REPEAT THEN . So he proposed treating those words as the basis for control graph composition, instead of limiting their use to their historical context. It seemed like a good idea in general, but nobody was really sure about it and it hung around for a long time as a "burning issue" that people didn't quite understand. Eventually I decided to engage with it. I soon realized that Wil's original proposal was a good idea at the core, but it was incomplete because it lacked the ability to manipulate the system-dependent tokens (think branch target addresses) whereby the primitives communicate, thus making some plausible constructs impossible to implement. One solution would have been to stipulate the location and size (e.g. one cell on the data stack) of control flow tokens - and in fact that might have been the best solution - but the committee was unwilling to pin that down. So I introduced CS-PICK and CS-ROLL as the finesse, with the understanding that, in many systems, they would be equivalent to PICK and ROLL. The lack of CS-DROP was an oversight, although in many cases it is possible to avoid it by avoiding CS-PICK when the result would ultimately need to be dropped. With the addition of CS-PICK and CS-ROLL, along with my support of Wil's idea and some amount of additional explaining and lobbying, the committee accepted the revised proposal and thus resolved the burning issue that had been hanging over our heads and blocking us from reaching closure.

[AntonErtl]

In this case the TC's unwillingness to pin down a specific size for control-flow stack items (and your interface that allowed different sizes) bore fruit:

In 1994 I implemented locals for Gforth, and I came up with the idea of automatic scoping. I implemented this with an additional cell per control-flow stack item (the address of the list of locals visible at that point). The end result was three cells: a tag (orig/dest/...), the address to be patched (for orig) or the branch target (for dest), and the list of visible locals.

A few years ago I started work on a static stack-depth checker. This needed another cell in the control-flow stack (the address of a structure that describes the depths of all the stacks at this point), growing the size of a control-flow stack item to four cells.

The lack of CS-DROP is not an oversight IMO. You carefully designed CS-PICK to only duplicate dests, so that a standard program cannot resolve an IF to branch to several THENs. Likewise, the absense of CS-DROP prevents that an IF is unresolved. One suggestion for CS-DROP is that it should only be allowed to drop dests. Recent discussions were along the lines that the committee wants to lift these formal restrictions, and specify in prose that each IF and AHEAD must be resolved exactly once.

[MitchBradley]

Re the "vision" question - hindsight is always clearer than foresight, and neither are all that reliable.

[ruv]

And there are two operations CS-ROLL and CS-PICK (with which CS-DUP, CS-SWAP, and CS-OVER can be implemented).

Take into account that these words work with only data objects of the orig|dest data type (copy only a dest). And the control flow stack can contain data object of many other data types too.

However there is no CS-DROP

: cs-drop ( dest -- )
  postpone true
  postpone until
;

orig cannot be copied, and so it cannot be just dropped.

Although, there is a proposal in this regard.

[SirWumpus]

Hmm. I had overlooked that subtly of the control-stack only holding orig and dest types. This resolves some questions, however it begs the question of how offset and/or address calculations might be achieved if you can't move dest or orig to/from the control-stack.

To flesh out the set, seems like there needs to be something like ds>cs cs>ds (or >C C> but I don't like the latter as it might be confused with character related operations).

[ruv]

the control-stack only holding orig and dest types.

Not only these. But cs-roll and cs-pick can handle only these ones.

seems like there needs to be something like ds>cs cs>ds

It seems, more often they are named as >cs and cs>
But they are system internals. They are difficult to use independently of whether the control stack is united with the data stack or separated from it.

[MitchBradley]

t begs the question of how offset and/or address calculations might be achieved if you can't move dest or orig to/from the control-stack.

There was no intention to let a standard program perform address calculations, since code addresses are not a standard thing. How could they be in light of an optimizing compiler? The intention is that orig and dest let primitives find their matching components. While they might be implemented as addresses, the general model is that they are opaque identifiers of specific instances of control flow primitives.

In the privacy of your own implementation, you can, of course, take advantage of implementation knowledge to manipulate them however you see fit.