World: r3wp

So, string (series?) CMP (perform integer or decimal CMP with SUB), 
plus BRAS that takes integer or decimal:

cmp: ["Sets a variable to -1,0,1 if two values are <,=,>" word! word! 
| any-string! word | any-string!]

bras: ["Branches based on the sign of a value" word! | integer! word! 
| integer! word!]

i do not know if we really need cmp, because you can just store the 
result of sub. but could be cleaner. i agree.

You can't sub a string. That's why I added the CMP above. Less than 
or greater than doesn't make sense for blocks.

Ah, get it. i thought compare takes two chars, and we have to loop. 
as a loop returning -1,0,1 it makes sense.

but i am not sure about this special case. sometimes i want to know 
where the difference occoured  and such things. So i prefer a selfmade 
loop, with rebcode. Except it turns out string-comparisons are very 
common.

If you expect the comparison to be common, why not make a subroutine 
and apply it or compose it in when needed? Not everything has to 
be an opcode, and the difference will be slight after the JIT is 
implemented.

because it is common in small loops: string-comparison, binary search. 
adds overhead in interpreter. is hard to detect for jit (its jit, 
not a heavy global optimizer).

the jit sees two comparisons and two branches. needs smartness to 
detect that this two comparisons can be folded in one because of 
cpu-flagword.

Fair enough. The string cmp would be a good idea to suggest to RAMBO, 
although I would suggest it be renamed to compare.

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.