World: r3wp

(Sorry to answer my own question) A state machine could be implemented 
as a brab with an indirect offset block at the head of a loop - that's 
a good use I guess. With an indirect label block (or absolute offsets) 
you could do the machine without the loop, just branches at the end 
of each state, but if you had to do runtime searching for the labels 
that wouldn't be faster.

So, no threaded interpreters. Oh well.

I was trying how fast is apply in new version but I'm not able to 
chceck it. I've got small test, I store precise time in a variable, 
run test, subtract precise time from stored time. But with new rebcode, 
second time is returned BEFORE rebocde is finished. Looks like if 
rebcode rust as independent task or thread (?).

Following test takes cca. 30secs on my computer, but REBOL says otherwise:

>> probe xt: now/time/precise muls probe xt - probe now/time/precise
23:10:45.859
23:10:46.015
-0:00:00.156

(forgot test function)

>> muls: rebcode [a][loop 1000000000 [mul a 2] return a]

Whe is the time printed before 'muls function is finished?

hm sorry, my fault :)

I forgot argument, better go to bad, good night :))

http://www.rebol.com/docs/rebcode.html<--- docs are up

New rebcode-enabled versions up: Core 2.6.51, View 1.3.51

Fixes since test 15 (as far as I can tell so far): The BRAB crash 
has been fixed in syntax - now the index can only be passed in a 
word, literal indexes have been disallowed (and were a little silly 
anyway, as they could be replaced by BRA or BRAW).

The great rename hasn't been done yet and BRAB is currently 0-based.

the poll seems to be a little "unpopular", only two voters and one 
of them is me

The other is me.

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.