World: r3wp

yes but combining operations need more tests so it will decrease 
overall performance. i do'nt see how i can do that without consumming 
more times to compile series of opcodes

It would require a more complex state machine, but since you wouldn't 
be starting over with every opcode it would execute less tests and 
branches per step than not combining. Think of combining opcodes 
as a kind of loop unrolling.

It would be not that different from your existing multi-byte opcode 
process, just for more opcodes.

i see

so in fact it could be performed by a static analyse of the code 
before ther real execution, and will result in addition of new byte-opcodes.

yep

You could even generate more of your interpreter by using more interesting 
macros, which would cut down on the programmer overhead of the increased 
number of states in your state machine.

like what ?

like iterative macros

currently i want keep ly source readable

but after the debuguing phase, i think i could compact the code with 
more macros, i agree

Perhaps you could specify your operations in a table and then go 
through it with a dialect processor like BURG - REBOL is good at 
that sort of thing. Then you could generate your interpreter from 
that table.

BURG ? sort of beer effect ?

No, BURG is a tool used to generate backends for compilers from a 
processor specification dialect.

:-)

It's for compilers written in C. I think you could do something like 
BURG in a few lines of REBOL though :)

Plus the input data, of course.

or you could add a a ReBurg function in the Rebol VM , to do that 
in my place :-)

don't knwo Burg dialect

*know

The dialect you would use probably wouldn't look much like BURG, 
since you are generating an interpreter.

Your generator would probably act a lot more like a peephole optimizer.

BTW, why rebcode thread is not on rebol.net ?

Few of the groups are. If I had to guess, it would be to avoid the 
reputation of vaporware. It has been a while since they have done 
a version of REBOL with rebcode, and it had some significant shortcomings. 
There may be no reason, though.

BrianH i test some changed with rebcode on my video emulation of 
the MSX, it seems than some native rebol instructions are more faster 
with image handling than rebcode

for example i can copy one image to another one with change instruction 
but  not using rebcode

rebcode can only handle byte series

Yeah, rebcode just cuts down on interpreter overhead, but since its 
operations are a bit lower-level they aren't necessarily as fast. 
For simple operations it can be much faster, but natives are just 
that, optimized native code.

Fortunately you can call the natives with the apply opcode and get 
the best of both worlds.

fortunatly :)

my interpreter  will be faster if any math operations could act on 
char (one byte)

and if more flags was handled

That isn't always the case with modern processors - some work faster 
with integers. I agree on the flags though, in your case.

could the T flag be set after a locial operation like AND ?

very usefull to test if a bit is set

*after a logical operation

for example, if i want to test the 7th bit , i do
and  var 128
ift [ do the job]

instead of doing
and var 128
eq.i var 128
ift [ do the job]

Whae does SETT do here?

sett ?

you mean

It sets the T flag based on the contents of a variable. I think it 
sets T to false if the var has 0, none or false, and sets T to true 
otherwise.

and var 128
sett var
ift [do the job]

Yeah.

Try it. My memory of the behavior of SETT on 0 is a little sparse.

i don't see any gain

It would be faster than a compare.

i use 3 instructions to test a bit in all cases

should have:
bit 7 [do the job]

:-)