World: r3wp

Sure you can, it'll just treat it as a deafult and move on to the 
next instruction without branching.

right, i forgot that.

which involves another thing, a range-check. not with smart jit, 
but with interpreter.

my solution is simply simpler IMHO.

But what does it do? This?

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

; Used like this:
sub a b
bras lneg lpos a
; a = 0
label lneg
; a < 0
label lpos
; a > 0

yes.

That would be faster.

but i guess 0 should not be default. probability for one of the others 
is higher, 0 be the last check.

or? when comparing strings, 0 is the most probable results, for all 
chars except list. makes a good default.

list -> last

with binary search it is not.

The only advantage to a cmp/brab is that you would need only one 
branch added. This would really be:

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

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

the advantage is that brab does a lot of work under the hood.

Also, if you just had a general CMP, you might be able to compare 
strings too. That may be too high-level for rebcode though.

My suggestion is exactly to compare strings fast.

and a general compare is as heavy as a bras. and makes most sense 
with a brab immediate following IMHO.

Sorry, I forgot that the integer above was an offset. Ignore bras.i/bras.d

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. :-)