World: r3wp

Volker was making some comments earlier about BRAB, but apparently 
didn't vote. I think he was in favor of the third choice, BRAB/BRABZ, 
or perhaps passing the base as a parameter. I prefer that third choice, 
but 0-based is my fallback.

Missed the voting.

It's still there, so vote!

I am not sure what i would need. With state-machines and such its 
no problem anyway, as i can choose the keys adjusted to brab's needs.

When loop unrolling by modulus, you need 0-based.

Teaming up with rebol 1 would be better, but then a little add is 
no problem too. And 0 would be slightly faster, as the cpu does a 
0-bounds-check automatic.

So i give a weak pro to 0-based.

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.