World: r3wp

Type thoroughly, type often :)

To me the BRAB example in the rebcode docs in section 2.8 is quite 
unclear. "The brab opcode allows computed branch offsets to be created". 
You can say the same about BRA, BRAF and BRAT as well. :-)


I have no idea what this opcode does, except that it looks vaguely 
similar to a SWITCH so it would be doing multiple branches somehow. 
It would have helped to see output results from the code and to have 
a better initial explanation on how to use BRA with integer indexes 
and an explanation of the B in BRAB. Do you agree?

BRAB branches to an offset selected from a block of offsets by a 
0-based index value. It can be used to implement C-like switch statements. 
The B at the end of BRAB means block.

Like with the other branches, if you specify the branch targets by 
label the assembler converts each target label into a numeric offset. 
This is called the fixup pass of the assembler. The assembler only 
fixes up branch labels for BRAB if the block is placed as an immediate 
literal in the statement.

what's the point of the 'n?

brab [4 6 8] n

it's not used elsewhere in the examples

The n is the index into the target block, treated as 0-based.

in that case it would also be nice with an example to see what the 
n can be used for, otherwise what would be the point in having to 
write it?

In that case, n=0 means branch to an offset of 4 after the brab statement.

The first (zeroth?) choice is 4, see?

yes I see that, but I can't see which line it'll go to.

is 4 "print 1"?

Yes, an offset of 4 takes you to the beginning of the print 1 statement. 
Branch offsets are calculated relative to the point immediately after 
the branch statement.

so that means each line of code is an offset of 2, or is it each 
element in the rebcode block?

Negative offsets take you back.
bra -2

takes you to the beginning of the bra -2 statement, an endless loop.

Each element in the code block.

I see... I think there should be something more clear about how the 
index works.

You can also reference the block of offsets through a word. Labels 
are not converted then - you must use numeric offsets that you count 
by hand (or in a compiler). Since these offsets are relative to the 
end of the branch statement, this block is only useful in one location. 
Also, when the rewrite phase comes back and they start using rewrite 
rules again, those hand-calculated offsets will likely be wrong. 
In theory, this could be used to implement a multi-state machine, 
but that kind of thing is deep magic that you should be doing with 
the parse engine anyways. It is theoretically possible to fill the 
block at runtime, which would technically be a computed branch, but 
this is so slow, awkward and unnecessary as to be ridiculous, especially 
for a branch block that can only be used from one location.

True computed branches require the use of the BRAW opcode. Of course, 
this opcode was removed from the engine in the latest revision and 
is not mentioned in the docs, so you are out of luck.

The index works like the index in pickz and pokez - that's not hard 
to understand. The real thing they need to explain better is how 
they count the offsets.

Henrik, they actually do a good job at explaining what the index 
is for:

The first argument to the opcode is normally a block, and the second 
is a zero-based index into that block. The value at that position 
is fetched and assumed to be the integer offset for the branch.

Now all they need to do is replace the word "computed" with "indexed".

Whoah, wait a second! Check this:

There is also a special case of operation. If the block argument 
to BRAB is an integer (created from a label), then the branch is 
made to that relative location plus the value of the index argument.
Now that's a computed branch!

But the current BRAB opcode doesn't work that way. Is this paragraph 
in error, or a sign of things to come?

I guess its an assembler-feature? it adjust the target-offsets?

soyou can branch relative to a fixed different location? Makes that 
sense?

But the syntax of BRAB doesn't allow this kind of thing (unless I'm 
reading the paragraph wrong). The block argument is type-checked 
to word! or block!, not integer!

The fixup pass doesn't currently fixup labels passed to BRAB unless 
they are in a block, and then that follows the normal behavior, not 
this "special case" behavior.

If it worked like the paragraph says, it would allow you to branch 
to a location relative to a fixed point, not the point of origin. 
This would effectively be my requested absolute branch!

Seems so. Where is the latest "release"?

Same place the rest of the latest releases are.
http://www.rebol.net/builds/031/?C=M;O=D

Isn't it shame, that the rewrite function from rebcode* context with 
the userdef-rule is missing in the latest rebcode?

I already found it usefull, here is an example: http://box.lebeda.ws/~hmm/rebol/rc_bunky7.r

As far as I can tell, it's just missing for now. If things go the 
way they have been, it'll be even better when it comes back.

I think, REBCODE will be great for teaching won't it?

Several of my suggestions and comments have been intended to make 
rebcode easier to learn. Easier to use is a side effect.

Porting knut to rebcode? :)

what is knut?

Typo, Knuth. Wrote some legendary programmingbooks, AFAIK he used 
some kind of assembler for examples. :)

Mix

It might be desirable to find out if any feature of his assembler 
is missing. Volunteers?

I don't have the Knuth books, but there is a port of Mix to the .NET 
CLR that I've been meaning to look at.

Does anyone know if Mix supports branches to addresses? Rebcode just 
branches to relative offsets.

see http://sunburn.stanford.edu/~knuth/mmix.html

Technically Mix was the virtual machine, Mixal was its assembler.

It has loads of things for i/o to devices like paper tape....I think 
rebcode could assume that happens as the mezznine level.

i and o could be series parameters

Oldes: the rewriting engine is mezzanine, so it can be easily added 
back by users. i will take care of releasing a script containing 
it as soon as we have an official version out.

so official version will not contain rewriting engine?

that's not decided yet, but probably not.

was it regarded being way too much high-level or so? Or inflexible, 
so that other ppl might find different way of how to aproach this?

the main thing is, that the details need to be discussed more (i.e. 
the grammar for the rules dialect, and things like this).

ok, thanks ...