World: r3wp

Maybe we can split the difference and have another opcode for absolute 
computed branches?

The method of assigning the block position to the word with the LABEL 
directive seems like a good idea - it was my first choice, but it 
didn't handle the offset calculations needed by the absolute-to-relative 
calculations needed by a relative BRAW.

Here is another (odd) way: Have a braw on a fixed position. Have 
all addresses relative to that braw. then jump to it. from it all 
addresses like absolute :)

Why not do both? Change

    'label word! (here/1: bind here/1 words insert insert tail labels 
    here/2 index? here)
to
    'label word! (
        here/1: bind here/1 words
        set here/2 index? here
        insert insert tail labels here/2 index? here
    )


No, since it wouldn't be set at runtime, it wouldn't be recursion-safe. 
The only safe way to do that would be to replace every reference 
to a label other than the label directive and the literal branches 
with  a constant value of its absolute offset, the one in the labels 
block. Doable, but awkward.

(That last one was directed at Gabriele)

(what is available on docu? i have to scroll a lot and can find it.)

can -> can't

Volker, so you would add one branch instead of an assignment to a 
temp variable and a subtraction. Sounds good, but branch prediction 
hardware would fall over if you JITed this kind of code :(

As for docu, there is the original blog, the succession of notes 
in the releases and the source. And our experimentation.

I guess till jit some things change anyway. and the branch to the 
branch would be absolute, so branch prediction should handle that.

doc: yes, there where some words to inspect. but i forgot the name. 
system/internals or something?

system/internals, rebcode-define and rebcode* for now.

system/internal/rebcodes

thanks. btw how secret is this? if i put scripts on my not so popular 
website, would somebody mind?

No problem.

A JIT with a peepcode optimizer would be able to recognize the pattern 
of an assignment to a temporary, subtraction from an address and 
branch relative indirect (3 instructions on x86, more on RISC) and 
convert it to a branch absolute (one instruction on x86, two on RISC) 
with no difficulty.

And vice-versa as well.

Volker, not secret, but changing so rapidly that I wouldn't suggest 
counting on it yet. Rebcode 10 and 11 came out within a day.

New version! Time to test...

Actually newest version is 12

That's the one I meant. Last one I saw mentioned here was 11.

You have to try editing url from time to time :)

Ok. Guys have a good weekend time for me to disconnect.

:)

Bye Jaime.

guys - take your time to do it right :-) We know "the date" is on 
14.November. I can't imagine what the rebcode will be like at that 
time, if we have two releases daily :-)

Pekr, we just can't win with you, can we?  You say speed it up but 
as soon as things speed up you say slow down. ;-)

No, nothing like that - I just said that with current speed of development, 
Microsoft should be scared, as ppl will soon realise .NET is big 
mistake ;-)

Should ifs pass the true-flag? So that this works like and:

rc-and: rebcode[f1 f2 /r ] [
 sett f1  ift[ sett f2 ]
 gett r  return r   
]

and a syntax-suggestion to make multiple statements in a line more 
readable:

rc-and: rebcode[f1 f2 /r ] [
 :sett f1 :ift[ :sett f2 ]
 :gett r :return r   
]

Volker, the first could be written as
rc-and: rebcode [fi f2] [
    and f1 f2
    return f1
]

Yes, but its more complex. i need a real shortcut-and.

like in rebol
 if p: find/tail s "x"[ not tail? p]

(artificial example, not my problem)

Translating to assembler style:
rc-and: rebcode [fi f2 /local l1 l2] [
    sett f1
    braf l1
    sett f2
    braf l1
    return true
    label l1
    return false
]

Yes, that was my other thought.

But i am curious about passing the true-flag back. IS there a reason 
not to do it, or just not addressed now?

btw will /local stay? thats an extra step. in rebol it is no problem, 
but in tuned rebcode its an extra assignment?

Yes, /local will stay, as it is just another refinement and the local 
variables are just other parameters that aren't used. Since the parameter 
passing to a rebcode function is performed by the outer interpreter, 
getting rid of local would mean getting rid of all refinements to 
all functions. BTW, the treatment of /local as a special situation 
is just an artifact of the help function.

i know. WHat i mean is, special handling of locals may be faster 
than handling that refinement. But you ae right, it would add complexety 
to the outer interpreter.

REBOL local variables are implemented with the USE statement - anything 
in the parameter spec, including /local vars, are just parameters 
you can reuse. For now, rebcode doesn't have anything like the use 
statement.

After checking, you can't pass the truth flag back, as inner rebcode 
blocks are implemented by recursing the interpreter, but you can 
pass variables back so your code can be implemented like this:
rc-and: rebcode[f1 f2 /r ] [
    sett f1 gett r
    ift [sett f2  gett r]
    return r
]

just want to ask - does one instruction here or there cause huge 
slowdown?

Volker, or a better (than the last one) assembler style:
rc-and: rebcode [fi f2 /local r l1] [
    sett f1
    braf l1
    sett f2
    label l1
    gett r
    return r
]

pekr: I tried doing this:

repeat i 100000 [<some rebcode function>]

vs.

<rebcode [] [repeat i 1000000 [rebcode stuff]]>

The pure rebcode example is much, much faster.

Pekr, it would depend on the instruction. Like in assembly code on 
real machines, some operations are faster than others. An assign 
or an add would be fast, a mul slower, and a div slower yet.

Adding an instruction in a loop will multiply the slowdown by the 
number of times the loop runs.

A nice thing to try would be forall in rebcode. We have apply now.