World: r3wp

As long as it's documented, it should be fine.

But how about a three-state if too? lesser/equal/higher 0? Could 
speed up binary search and such?

(That reminds me: I need to finish reading the docs)

You mean a general CMP?

yes.

I hope that means a branch with three target.

( 2 target and next comand )

That would be faster if rebcode was implemented in x86 assembler, 
but how about other platforms? How would you make this faster if 
the engine is pargrammed in straight C?

For now we have an interpreter. For straight c, it would not slow 
down at least. And with assembler a braw would be as fast as a brab, 
so we would not need it. althought if c shall be an option, brab 
matches to switch.

How would you do it, like this?

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

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

; And then use it like this:
cmp.i t a b
brab [leq lgt] t
; Less than
label leq
; Equal
label lgt
; Greater than

No, i thought about a branch with 3 targets. misunderstanding, not 
cmp then.

sub left-elem right-elem
bra3 to-lesser to-higher left-elem
; here they are same

Well, brab has three targets in the example above: 0, 1 and default.

yes, but bra3 has -infinite..-1, 0, 1..infinite

which is supported by cpu-flagwords.

Then you are thinking like this?

cmp.i: ["Do one of three blocks based on if two values are <,=,>" 
word! | integer! word! | integer! block! block! block!]

cmp.d: ["Do one of three blocks based on if two values are <,=,>" 
word! | decimal! word! | decimal! block! block! block!]

; And then use it like this:
cmp.i a b [
    ; Less than
] [
    ; Equal
] [
    ; Greater than
]

something like this. But imho it does to much. and it should work 
with gotos, is it possible to jump out of a blick?

No. That is why I prefer my first suggestion.

that would be slower.

the typical thing is that you really subtract (or compare) and follow 
that by two conditional branches. no lookup like with brab needed.

Not much slower, really. If you specify a literal branch target block, 
both my suggestions would be translated to the same machine code 
by a JIT.

next s1 next s2
seti char s1  sub char s2
bra3 to-equal to-higher
; we are lesser here
label to-eqaul
next s1 next s2 ; check length..
bra loop
label to-higher ; we are higher here

It was you who claimed a little extra add is to slow.

The jit has to realize that your compare results in -1, 0, 1, that 
you add 1, and then that you brab. Possible, but needs more insights.

which bloats jit.

That would require a 3-valued comparison flag to be set inside the 
interpreter. Right now there is only a true/false flag.

No, the bra3 takes a variable with the result of a 'sub. with jit 
that is a very small peephole, easy to detect.

A JIT would know that a cmp would only set t to -1, 0 or 1, and then 
know what to translate a following brab on it to.

Your example bra3 there didn't act that way - the result of a sub 
isn't referenced. Do you want to fix your example?

You cant do a brab on a -1.

So you have to track three statements. And to give always that order 
or the jit needs to look even deeper.

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.