World: r3wp

0-based doesn't need to add or subtract anything if n is already 
0-based, like it would be for modulus calculations.

You have to add that 0 to the table-base. table-base may be known 
by pc and slightly faster to access if not dynamic, ubt i doubt the 
difference is big.

The table is a block. The block reference has a position. That position 
is the base. All these indexes are relative to that. If you specify 
0-based or 1-based, that 0 or 1 can be hardcoded (faster in the interpreter) 
or can be replaced with 0-based or 1-based machine instructions (faster 
if you JIT, as both types are common, and other bases require rebasing 
to 0 or 1 first).

x86 has instructions that directly correspond to pick/poke and pickz/pokez, 
but other bases require some math (or segmenting).

This isn't like change or copy - branches are supposed to be fast.

The block reference has a position.

 Yes. And i can base on that at compiletime. if i use 1, i decrement 
 that position at compiletime. when i add, its as good as 0-based. 
 if i know at compiletime the offset is something else, i can adjust 
 too.

BTW if you jit, never think branches are fast..

New REBCODE release: www.rebol.net/builds/031/rebcode15.zip

note: rewrite engine is disabled.

First impression:
- Yay! setw/getw, rotl/rotr, bswap, change = change/part, brab 

- I hadn't thought of those, but cool: ext8/ext16, break now breakt/breakf, 
making rebcode* now a field in system/internal

- Questions: Haven't done the grand renaming yet? Rewrite getting 
rewritten? Does brab work yet (it crashed for me)?

renaming will be next, then a public beta will be released. brab 
should work, but i haven't tested it, and not sure if anyone tested 
it yet...

Crashes with literal integer indexes into the label block. Does work 
with index assigned to a word - apparently 0-based right now.

; This works

do rebcode [x [integer!]] [brab [a b] x return -1 label a return 
0 label b return 1] 0
; This crashes

do rebcode [] [brab [a b] 0 return -1 label a return 0 label b return 
1]

Also, as far as I can tell, indirect label blocks just don't work, 
and for indirect offset blocks the position of the block is ignored 
and the index is counted relative to the head of the block, not the 
current position. If these two cases stand as is, there will be no 
reason to support indirect offset block addressing at all. The current 
reasons to support indirect branch target blocks are to have the 
label words used to make offset calculations at runtime (effectively 
making the branch target an absolute offset), or to play with the 
branch block position for obscure reasons. Relative branch targets 
are only valid from one location, so there is no point to putting 
them into a runtime value like a block referenced through a word 
when they can only be used once.

(Pardon the awkward phrasing - it's a complicated topic and I don't 
have time to rephrase. Be back later)

indirect labels: no, labels can only be looked up by the assembler. 
there's no way to look them up at runtime.

Then there is almost no point to referring to the label block indirectly. 
You could theoretically swap indirect offset blocks at runtime as 
part of a state machine, but you would have to calculate offsets 
manually, and couldn't use rewrite rules then because the offsets 
would likely change in unpredictable ways.

Since indirect offset blocks would be harder to JIT, why bother to 
support them at all? Only indirect label blocks would be really useful.

(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!]