Break / Branch?

[kripken]

This repo currently has br: branch to a given label in an enclosing construct. I assume the intention is that

(block $block
  (branch $block) // goes to $more
)
(block $more)
)

Is my understanding correct?

If so, isn't this more of a "break" than a "branch"? We not are not actually branching to $block, we are going to $more in fact. But the name "branch" implies to me "branch to". It seems nicer to do either

1. (branch $more), which says "branch to $more" (where we actually branch to), or
2. (break $block), which says "break on $block" (just like a C/JS/etc. break on a labeled block),

over the current state, which says (branch $block) but actually does not branch to $block.

Obviously 1 is a forward goto, which is bad. How about 2?

[kripken]

(bonus: we don't need to rename the br ;)

[sunfishcode]

Another approach is to rearrange the syntax. Instead of putting the label at the top of a block, we could put it at the bottom:

(block
  (blah)
  (blah)
  (blah)
  $label
)

which makes it quite clear where control goes on a branch with that label.

[rossberg]

I agree that "break" is the more adequate term.

@sunfishcode, labels are symbolic names for AST nodes, not "positions" in sequential code. The syntax you propose would not be good fit for that.

[sunfishcode]

@rossberg-chromium It's a new language, so we can make labels be whatever we want. This issue appears subjective at this point.

[lukewagner]

@rossberg-chromium You could consider the syntax for the block nodes to be (block ... $label), so it's still just syntax for an AST node.

Furthermore, if we do the analogous thing for loop:

(loop $back
  (blah)
  (blah)
  $forward)

then it seems 10x more readable and intuitive than (loop $back $forward (blah) (blah)). Also, I do think "branches" is the right metaphor here as we're designing an assembly language (it's in the name!).

[rossberg]

@sunfishcode, well, if it involves changing the semantics of labels then it would be a change to the language as it has been spec'ed and implemented so far (e.g. in v8-proto). So in that sense, it's not just subjective.

@lukewagner, the name notwithstanding, a language with nesting structure and expressions is pretty remote from a "real" assembly language (for good reason!), so I'm not sure that is too strong an argument. The fact that we have breaks rather than random branches is a direct consequence of that structure. Sure, we could tweak syntax in various ways, but are you sure this isn't trying to shoehorn the language into a form that does not actually reflect its actual structure anymore?

[kripken]

I agree with @rossberg-chromium - yes, this is an "assembly", but it's an AST-based assembly. Doing something that seems odd for an AST is an unnecessary weirdness. And in AST-based forms, it is natural to see

L1: do {
  ..
  break L1;
  ..
} while (..)

e.g. in JavaScript, which is going to be a major point of comparison since this is an assembly for the Web (but the same is also in Java, etc.). It seems better to not have unnecessary odd differences, like putting the label at the end.

However, if people feel strongly that "branch" is meaningful here, then how about "branch out of"? (as opposed to the implied "branch to") That's novel, which is a downside, but at least it could work with the labels in their natural place on the top.

[sunfishcode]

@rossberg-chromium I expect we'll end up with the same binary encoding either way, so even if you impose a formalism on this discussion which makes it technically a semantics question, it's still a subjective one.

[titzer]

In which context do we need to spell out whether "br" stands for "break" or
"branch"? Can't we just simply refer to them as "br" and "br_if" and leave
the interpretation up to the reader (as long as the semantics are described
succintly)?

On Wed, Nov 4, 2015 at 9:08 AM, Dan Gohman notifications@github.com wrote:

@rossberg-chromium https://github.com/rossberg-chromium I expect we'll
end up with the same binary encoding either way, so even if you impose a
formalism on this discussion which makes it technically a semantics
question, it's still a subjective one.

—
Reply to this email directly or view it on GitHub
#445 (comment).

[kripken]

In the s-expression format, yes, br can stand for either. But in AstSemantics and in the future spec, we'll need to name this thing.

And it would be nice to not have some people call it a "branch" and others a "break". That already happened now: reading s-expression testcases, I read "break" in my head, then was discussing something with @sunfishcode, and he said "there is no break, there's just branch"...

[qwertie]

I'm not sure why there appears to be disagreement. It seems like, in programmers' minds, the meaning of "break" and "branch" is well-established. This is break:

L1: do {
  ...
  break L1;
  ...
} while (...);

And this is branch:

do {
  ...
  goto L1;
  ...
} while (...); L1:

So if it's "branch", the label must go on the end in the text format. Anything else is confusing.

[kg]

I expect we'll end up with the same binary encoding either way

I don't think it's reasonable to dismiss someone's concerns with this, given that we've actually made zero effort to verify that our changes don't regress binary encoding efficiency or significantly alter the binary representation.