World: r3wp

You would still need it to compute relative branches from absolute 
offsets. Plus, by making it a seperate operation you can be more 
likely to have the developer remember to make their label words into 
local variables.

anyway, thinking more about it, probably BRAW was intended for things 
like switch, as Volker suggests above... in that case relative offset 
seems natural.

yes, you have, but you have anyway...

The whole reason I came up with this was because BRAW was relative. 
If you changed BRAW to absolute and wanted to do a computed relative 
branch, you could do so with the same two added instructions. If 
you can come up with an occasion to do a computed relative branch 
please tell me, because I can't. All of my examples either require 
absolute or are better with it.

a function table could use a computed relative branch

i.e. you have a "table" of APPLY instructions and jump to the one 
you want.

but... i'm just playing the devil advocate. i don't know why Carl 
choose relative.

Really? Only one that would be used from a single branch statement. 
If that table is reused you would have to recalculate it for the 
new branch location.

For example, there are two ways that ProtoThreads is implemented. 
One way uses switch statements, using a variation of Duff's device. 
The other uses computed branches on compilers that support them. 
The computed branch version is faster, and branches to an absolute 
address. Computed branches to absolute addresses are used in threaded 
interpreters as well.

Switch statements are compiled to relative branches, but those branches 
are computed at compile time rather than run time - in that case 
there is only one branch statement so it's OK. A switch statement 
can be implemented with the other, direct branch statements.

I think Carl chose relative because then he would only have to implement 
one way to branch, relative. In practice, even the non-computed branches 
to label words (rather than literal numbers) are absolute: The assembler 
converts them to relative with the statement  here/2: label - index? 
here  , the same calculation you would have us perform at runtime 
before a relative BRAW could be used.

Thinking further, you could use relative computed branches to implement 
switch statements, though absolute would work too.

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.