World: r3wp

:)

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?

Gabriele says he relayed my concerns, but the rewrite of fix-bl hasn't 
been incorporated. Sounds like Carl hasn't agreed.

then there must be some reason :-) let's wait for an explanation. 
IMO Carl is opened to suggestions ...

rebcode12 added GLT (a < b < c) and GLTE (a <= b <= c). It's nice 
to have intervals, but in practice I use intervals that are open 
from one side and closed from second side or vice versa, i. e. (a 
<=b < c)

As for how large the compiler would be, it depends on the source 
language and how ambitious you are. If the language is REBOL-based, 
then at least I don't have to write a lexer. It would depend on what 
kind of optimizations you want to incorporate and how static you 
are willing to make the language dialect that you want to compile. 
Type inferencing would add a lot too, but would have a major benefit 
when translating from a dynamic language like REBOL to a static one 
like rebcode.

Parse would help a lot, obviously.

Carl is open to suggestions when he has time to hear them. He is 
very busy, and niether he nor Gabriele have suggested I contact him 
directly about this.

ah, you talk about separate compiler? I thought you will just JIT 
rebcode?

That's Carl's job. A job which could make rebcode twice as fast to 
be sure :)

where in rebol such stuff as JIT belongs? Would it be just a function 
you would point to a rebcode code?

In theory, it would be an implementation feature of the rebcode VM. 
Now that you mention it though, there are a few JITs that can be 
called as a library, such as libjit, LLVM and libtcc. If you took 
the finished rebcode code block you could translate it to one of 
their intermediate languages and have them translate it to native 
code. Sort of like a to-native function.

The apply and do opcodes wouldn't survive the trip though.

hmm, but then you just will have few helper funcs in rebcode to speed 
your code execution here or there. OK, so you produce JIT using some 
external library, but how you link it back to rebol? (maybe wrong 
question not understanding properly how this stuff would work :-)

Rebol would have to provide better hooks. To access rebol-values 
directly.