World: r3wp

Submitted as "COMPARE rebcode operation for string comparison."

BRAS (branch on sign) submitted too. We'll see what happens, or even 
if the opcodes are finalized.

For those that may be concerned, BRAW is gone from the new version.

Documentation note: The docs say that APPLY doesn't work with action! 
functions, but it does work with the ones I have tested.

Which ones do you test?
>> f: rebcode [a b /loca r] [apply r ** [a b] print r]
>> f 3 5
** Script Error: Out of range or past end

Sorry, mixed action! with op!

I tested power so far. I was going to test the actions that had no 
equivalent opcode (not many).

Add works too.

seems like 'bras being dismissed (low priority) but string comparison 
as TBD in RAMBO?

I hadn't even looked yet. Some of my proposals have been made useless 
by the removal of the BRAW opcode (RAMBO 3942, 3924). There's no 
point to label offset values if you can't use them. Oh well, so much 
for that.

I kind-of expected bras to be rejected. There was a workaround using 
min and brab, slower but doable. This is why I put "Undetermined" 
as the priority when I submitted it. Compare seemed like a good idea 
though.

I would like to know how is it with trapping the errors? I read available 
rebcode docs, and it seems to me that you can make your rebol process 
to fail by wrong rebcode code, right? Is it  theoretically possible 
to wrap rebcode call into 'try, so if it fails, error is returned 
instead of process crash?

You can quite easily make REBOL core-dump using rebcode right now. 
No try is going to catch that.

hmm, I would expect to go this route using libraries code, but with 
rebcode? aren't you manipulating rebol internals only? How can you 
get past the boundaries of e.g. string or binary to cause such core 
dump?

I've done it dozens of times during my testing. I should really put 
together a list of rebcode sequences that can crash REBOL.

simply what I wanted to ask - if that is normal with such VMs in 
other languages or we simply do allow such crashes because of various 
reasons (e.g. preferring speed, not doing checks etc.)

Most of the type-specific opcodes just assume that the data is of 
the correct type, with little to no runtime testing. It is quite 
easy to corrupt REBOL internals this way.

ok, good to know for me rebcode can be "insecure" in a sense that 
you can kill the process ...

JVM and CLR VMs do a lot of testing of their bytecode sequences before 
execution, as part of their security testing. Until someone makes 
a type-inferencer for rebcode, it won't be safe to use without manually 
reviewing every function before use, or only using rebcode generated 
by trusted compilers. It is much like machine code in that way.

Code from trusted programmers can be used too :)

well, still have to have occassionally crashing rebcode, than libraries, 
which will always be regarded a security flaw ...

I haven't been able to come up with a way to exploit these crashes 
(nor am I likely able to do so), but crashing the process repeatedly 
can be a good denial-of-service technique. Type flow analysis is 
a must for rebcode, so be extra careful with your data type testing!

hmm, that is true, imagine website providing some service and someone 
passing intentionally wrong values to your fields etc. :-)

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!