World: r3wp

APPLY is quite slow as well, at least when compared to rebcode in 
general.

I guess its because of all of tha context navigation which rebocode 
is freed of.

darn, why does that damn "o" always get added when I write rebcode 
quickly..

I think that function calls recurse into the interpreter.

BRAB is for branch tables like that generated by switch statements 
in C. Words in the target block are changed by the assembler into 
integer offsets to their associated label statements. Any other use 
is only appropriate for compiler-generated rebcode.

As for an equivalent to NONE?, SETT might work.

Looking back on this group, it seems that the APPLY bug may have 
been fixed. Also, BRAB is good for use on the results of CMP or SIGN.

As for reversing the bits in a byte, have you considered a binary 
lookup table?

steeve... told you brian was the reference here  :-)

It's been a while - for some I had to go back and look at my own 
posts :)

is rebcode still incapable to lookup objects?

(still as in... did the last version still have that limitation)

That was part of the planned upcoming features, and then they stopped 
updating it. I recall creating a comprehensive proposal...

You can still APPLY IN and then GETW or SETW.

rebcode really has to be part of 2.7... if we could just have object 
lookup, that would allow me try to make a few tests with liquid and 
mayb optimise so its about 10-30 times faster at managing the dataflow 
 :-)

Have you tried it with APPLY IN and such? How is the speed compared 
to REBOL?

I have not yet done any rebcode tests with liquid, as so far, its 
always interactive enough, so as to not require it... but I am going 
nuts with the engine  ;-)  liquidator is a testament to its stability 
and another user here is helping me push the enveloppe to  :-)


but obviously, It will come to a point where pure processing will 
be needed and in such a case, speed will always be a factor.

going nuts as in "I'm having a lot of fun with it"  :-D  the apis 
is pretty complete for most gui and procedural

(needs)

I didn't know about APPLY IN ... I might just do a quick try in a 
little while...  does 'APPLY support refinements?

Yes, as positional true/false arguments. IN doesn't have any refinements.

ok ... yes... I remember that part about the ordering of apply...

If you change the order that the refinements are declared in the 
function, you will need to change all calls by APPLY to match.

I think true/false will work - it might need true/none.

its probably true/none

It's probably both.

hum... in any case, thanks for remining me about APPLY IN  :-)  you've 
revived my interest in rebcode (even if I might now rely on some 
features of 2.7)

here am i ^^^

It is really the best way to work with objects in efficient code, 
so much so that I requested an IN opcode.

Hi Steeve!

glad you did  :-)

IN doesn't work with structs though, so I requested a set of struct 
opcodes to work with them (SET.S, GET.S, ...).

that would probably be even faster.

since its a simple shift

I meant offset

For structs, yes. For objects, IN and GETW/SETW would be faster since 
you can cache the looked-up word.

It's not that bad a technique in REBOL code either.

Path evaluation has a lot of overhead.

Any questions, Steeve?

BrianH, what is the most rapid, to use a do [my-func var] or an apply 
?

Apply.

hum, and if i have severall apply to do (in sequence) ?

APPLY in a LOOP block or something. Even then, it is much more efficient 
to translate to rebcode and inline when you can - APPLY overhead 
is significant, and DO overhead much more so.

ok

have another question on system/internal/assembly*

can i disactivate the label parsing/replacecing to gain speed when 
i build rebcode functions

?

i d'ont use labels

but i build many many rebcode functions in real time, i need speed

i use a parser to convert Z80 opcodes into rebol opcodes