World: r3wp

So you can specify numeric offsets, but they are only practical for 
a literally specified block. And you can still specify label words 
in an indirect block, so those are still useful too. Cool!

How about offset as argument? we can have 0, 1 or 65 then. Switching 
on letters. DO not know if that makes sense. :)

Volker, we already have that in the BRA opcode

I mean switch-ondex with offset.

brab -> brab .. 1, braz -> brab .. 0

Hmm, -1 0 1 code sometimes for lesser, equal, higher. brab .. -1

I think you still need the b in brabz to designate the block you 
are branching on.

Its about that little number at the end, not about my typos. ;)

Assuming you are going for both I mean.

No, i go for infinite.

My base is not hardwired, but an argument. Will be usually 0, 1, 
but could be other vlaues too. -1 would give three-state if. nice 
for stable sorting maybe.

Oh, you mean the word n in his example. If you know the value of 
n ahead of time there would be no point to using brab - you could 
use bra.

Grrr, i cannot express myself?
 BRAB [lab1 lab2 lab3] n 1

-1 could be treated as a default value, and you would put its associated 
code right after the branch. But I get your point.

Or for that matter, you could do an add or sub to n before you use 
it.

Yes, but thats an extra step. In brab it would be cheap i guess.

Then you would add an extra step to the common cases of 0 and 1, 
internally?

Yes, but that step is there anyway? I guess some immediate number 
has to be added.

Either way your extra step would result in the same number of instructions 
after JIT.

With jit yes. with interpreter not. on  screen not too.

No immediate number has to be added for 0-based, and 1-based can 
be hardcoded.

And i guess when switching adding something is quite common.

That's how C compilers generate it.

You have to get the table-base from somewhere and add that.

So even a 0-base may need to add or subtract something.

If the table-base is a pointer to the table (as it is here) any rebasing 
would require math. The question is whether you want to do that math 
every time, or just when you need to.

You need to do it every time you switch. Its not 0-based, its always 
table-based.

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