World: r3wp

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.

Henrik - I know - but guys here are talking about rebcode only stuff 
- simply what other opcodes to add, to save e.g. 1 single rebcode 
operation. So I am just trying to find out, if even in some longer 
rebcode loop, one operation here or there makes any significant difference? 
Of course I am the last who would not wish rebcode stuff being optimized 
as much as possible :-)

OK, million iterations of loop is million opcodes. How much does 
it take? Just asking, theoretically :-)

well, it's usually very literal? with regular assembler you can count 
the amount of nanoseconds or CPU cycles it takes to do do some operation. 
I don't know if you can do that with rebcode. it gets more and more 
difficult, the higher level you go

That answer would require some testing. In theory it would be

(instructions to execute the function of the opcode) + (instruction 
overhead of executing any opcode) + ((overhead to retrieve a parameter) 
* (number of parameters))

Depends how often that instruction runs. In the discussion about 
relative braw for example: Usually that is no problem. But if you 
write an interpreter in rebcode, it would be: braw, do a little bit, 
braw, ... And then the braw could have a huge impact, as the little 
bits may be just "add" or such which are fast. In that case an absolute 
braw may give 10%.

ok, thanks ....

Yeah, with braw I wasn't concerned with the 2 opcodes you would have 
to add before any call to braw to make it usable; I was more concerned 
with actually being able to get the address offsets to compute with 
without having to write a compiler (which I am going to do anyways, 
just not right now). That was why I came up with that HERE assembler 
directive.

Still, an absolute braw would take less than half the time that using 
a relative braw takes when you have to compute those offsets.

Have you tried to communicate that with Carl?

BrianH - you seem to be skilled in that area. What speedup do you 
think compiling rebcode could achieve? And - how large the compiler 
would be?