World: r3wp

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.

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.