World: r3wp

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

i attempt to do a Z80 emulator

It really doesn't gain you much speed. The label fixups are done 
once, at rebcode function creation time. After that it just calls 
the offsets - the label statement is a noop. I only do straight offsets 
when generating code (like you are). Be careful though, as the offsets 
are calculated from the end of the branch statement, not the beginning.

This only matters when writing your own offsets. I only noticed when 
I started using the BRAB opcode, and its predecessor BRAW.

anyway, can i replace assembly* by a dummy function ?

You can replace assembly* with a Z80 assembler even.

ok

i noticed that i can join the code of  2 rebcode function without 
re-assemble them

Remember that the current assembler* doesn't do much, and even that 
is done at rebcode function creation time. It has no effect on execution 
time.

If you join these function blocks after the rebcode function is created, 
you may have context issues. It is better to join them before assembly.

yes but i try to do emulation + a debugger , so Z80 opcodes are converts 
step by step

i have no context issues, cause all words i use have the same context

there is no local words in my rebcode functions

You can do code snippets for your emulation/debugger, and concatenation 
for direct execution.

it's what i do

As long as you are careful the semantics shouldn't change.

Remember that these branch statements group statements together into 
basic blocks, so you should break up your code into snippets on boundaries 
between these blocks.

that why i don't use branch statements

branchements are controled outside rebcodes functions

For non-generated code, the only useful branch statement in rebcode 
is BRAB. All others have better structured equivalents.

BTW, the English word for branchements is branches.

i have a main loop wich do the branchements and call the rebcode 
routines

sorry

Just trying to help :)

Are you doing a compiler or an interpreter? A compiler would be faster, 
but would require you to translate branches.

it's an hybrid way

i try to do the two things

A JIT compiler, perhaps?

sort of like a JIT ?

hehe

first i parse Z80 opcodes and execute them step by step, then they 
are concatened to build sub-routines and cached, if sub-routines 
are mantory another time, then i call cached sub-routines instead 
of reparse the opcodes.

*mandatory

(requested is better)

Do you do basic block analysis of the source opcodes to determine 
where the subroutine boundaries are? For that matter, does the Z80 
have indirect branches?

;-_-

Sorry, I don't speak IRC.

yes indirect branches exist

but it's not a problem, the management of branches is done in real 
time, it's in a stack, so i can manage fixed as indirect branches.

How common are they? Can you analyze them to determine their destinations 
to convert them into branches or calls?