World: r3wp

I agree with kru -- pity there is no option for making them look 
like refinements
  add/i
  add/d
  add   -- default is /i or /d or whatever is chosen

suggested that to. Was told its technially no option, they must be 
words.

or add-i/add-d. More REBOLish than dot.

exactly ....

I-am-already-used-to-rebolish-way :-)

The only advantages I can see to the dot (as opposed to the - ) is 
that it is less visually imposing and that it is easier for me to 
reach on my keyboard. These advantages are not insignificant, though.

Either dot or - would be OK to me.

here is a poll

Carl said: What I am thinking of for BRAW is this:

   BRAB [lab1 lab2 lab3] n


If N is out of range, the BRAB does not happen. That allows DEFAULT 
case without needing to compute it before teh BRAB.

Should BRAB be zero-based or 1-based?

(see checklists for the poll)

Are the labels statically replaced with offsets like they are with 
bra, done with runtime lookups of the label declaration, done with 
label offsets assigned to the words, or done some way that hasn't 
occured to me? Can numeric offsets be used, and if so are they absolute 
(within the block) or relative?

As for 0-based versus 1-based, let's compare:
0-based

- would allow branching on the basis of a modulus calculation, or 
other calculations that can result in zero

- would be more useful for implementing Duff's Device style switch 
statements, which I have found useful so far
1-based

- is more REBOL-like (if such a thing can be said of a goto statement)

- effectively has a 0-based branch with the default of continuing 
on (not as useful for Duff's Device stuff, as the 0 branch is usually 
the last in the code)

- is in keeping with the rest of the 0-based opcodes having the letter 
z on the end, while BRAB doesn't

I vote for 0-based, or both (BRAB/BRABZ).

If both is added as a choice to the poll, I'll change my vote from 
0-based.

Last question, can the block be passed in a word? Keep in mind that 
I am not requesting this, as there would be some negatives:

- You couldn't replace the labels statically with offsets in the 
assembler
- It would likely be slower and harder to JIT
- Copy/paste or compose can accomplish the same thing

Still, this deals with the most common usage scenario that I've found 
for computed branches so far, so I'm really pleased!

(by the "this" in my last statement, I meant the BRAB opcode, not 
indirect blocks)

By the way, if the block is required to be a literal, numeric offsets 
could be decided to be specified in either absolute or relative form. 
If you allow the block to specified through a word, absolute numeric 
offsets are the only practical option - this is probably another 
negative for label blocks in a word.

Common usage scenarios for BRAB would be C-style switch statements, 
state machines and token-threaded interpreters. Direct-threaded interpreters 
would still need BRAW, though are only practical when branching to 
an absolute offset so the current BRAW wouldn't work for them either.

If we have BRAB, can anyone think of a decent use for a BRAW to a 
relative offset? Every other usage of computed branches I can think 
of requires branches to absolute offsets to be at all practical. 
Have I missed something? Once we have BRAB, is there any reason to 
treat BRAW as a relative branch, besides simple implementation issues?

brab does accept a word for the first arg. offsets still need to 
be relative.

if the block is literal, the assembler takes care of replacing labels 
with offsets.

So you can specify numeric offsets, but they are only practical for 
a literally specified block. And you can still specify label words 
in an indirect block, so those are still useful too. Cool!

How about offset as argument? we can have 0, 1 or 65 then. Switching 
on letters. DO not know if that makes sense. :)

Volker, we already have that in the BRA opcode

I mean switch-ondex with offset.

brab -> brab .. 1, braz -> brab .. 0

Hmm, -1 0 1 code sometimes for lesser, equal, higher. brab .. -1

I think you still need the b in brabz to designate the block you 
are branching on.

Its about that little number at the end, not about my typos. ;)

Assuming you are going for both I mean.

No, i go for infinite.

My base is not hardwired, but an argument. Will be usually 0, 1, 
but could be other vlaues too. -1 would give three-state if. nice 
for stable sorting maybe.

Oh, you mean the word n in his example. If you know the value of 
n ahead of time there would be no point to using brab - you could 
use bra.

Grrr, i cannot express myself?
 BRAB [lab1 lab2 lab3] n 1

-1 could be treated as a default value, and you would put its associated 
code right after the branch. But I get your point.

Or for that matter, you could do an add or sub to n before you use 
it.

Yes, but thats an extra step. In brab it would be cheap i guess.

Then you would add an extra step to the common cases of 0 and 1, 
internally?

Yes, but that step is there anyway? I guess some immediate number 
has to be added.

Either way your extra step would result in the same number of instructions 
after JIT.

With jit yes. with interpreter not. on  screen not too.

No immediate number has to be added for 0-based, and 1-based can 
be hardcoded.

And i guess when switching adding something is quite common.

That's how C compilers generate it.

You have to get the table-base from somewhere and add that.

So even a 0-base may need to add or subtract something.

If the table-base is a pointer to the table (as it is here) any rebasing 
would require math. The question is whether you want to do that math 
every time, or just when you need to.

You need to do it every time you switch. Its not 0-based, its always 
table-based.