World: r3wp

will print out ?unset? instead of freq == pi

No, speedup.

rc: rebcode[][
print pi
	setd pi 3.14159265358979
	print pi
set freq 0.0
	setd freq pi
	print freq
]
rc

setd test only for decimal, it does not change type otherwise.

pi is already a decimal..

exactly as Volker said: if FREQ is not a decimal!, you cannot use 
setd freq ...

ok, thanks

Oldes, when you use the branches other than braw, any label word 
targets are converted to literal number offsets, with the offset 
calculations being performed by the assembler. On the other hand, 
the target word of the braw branch is looked up at runtime, so you 
need to assign the offset to that word yourself, usually through 
a lookup table like I specified above or through calculations.

Would be nice if those tables could be build by hand. is it possible 
to access them for calculations?

Volker, the problem with declareing the distance between two offsets 
as data is that the assembler doesn't currently have any way to even 
get those offset values as data. That is what my HERE directive proposal 
does. You have to do this kind of thing in the assembler, because 
until the rewrite rules are done operating the offsets can't even 
be known.

But the assembler knows this values internally and could be extended?

compilers with external assemblers pas such math to the assembler, 
emitting"label - base-address"

in assember we could have an "offset" for that. "offset target-label 
braw-label"

Now, it would be possible to have the offset values be referenced 
by label name in your calculations, but that would require some changes 
to the assembler as well, because those label words would also need 
to be replaced with literal offsets because of binding issues. This 
can be done in the same assembler phase as the branch label fixups. 
I actually made a similar change to the assembler to implement that 
HERE directive I proposed.

It would not be difficult to implement this. You wouldn't need to 
change the native code at all - even I could do it from here.

For now we can do this:

rc: rebcode[v][
 probe v
 sub v 1
 add v v
 braw v
 bra do-1  bra do-2  bra do-3 bra do-4
 label do-1 probe 1.1 probe 1.2 probe 1.3 bra bye
 label do-2 probe 2.1 probe 2.2 bra bye 
 label do-3 probe 3.1 probe 3.2 bra bye
 label do-4 probe 4.1 probe 4.2 bra bye
 label bye 
]
rc 1 rc 2 rc 3 rc 4

All that would be required would be that here directive, probably 
renamed to offset, and some code to perform the label-word-to-offset 
switch.

where to look for the assembler-source?

probe rebcode*

If I can set aside the time to this weekend, I'll do it myself.

The side effect of this is that you wouldn't be able to use label 
words as variables for other reasons in your rebcode. Is everyone 
OK with this restriction?

Maybe we could access the label-table of the last definiton? And 
preparing own tables? could be blocks. then

That won't work. Every rebcode block gets its own label table, which 
is just a block, not a context, and is thrown away after the label 
fixups. These offsets need to be constant - a label table could be 
modified by the calling code. Really, it's easier to do the fixups 
in the fixup phase - that's what it's there for.

Have to examine assembler before knowing such things :)

Well I have already :)

Thats why i try to get away by just asking you :) But seems i should 
look too.

Actually, I pored over every line of code, tested most of the opcodes 
too. I've been taking this rebcode development very seriously, making 
suggestions, finding bugs. Trying to keep from making too much of 
a jerk of myself. I expect that I'll be using and generating a lot 
of rebcode in the future so I want it to be the best that it can 
be.

If anything, the conversations with Gabriele remind me of those we 
had on the list where we reverse-engineered REBOL's context handling, 
back when it wasn't documented.

I agree. For small byte-crunchers its high-level enough. Maybe  it 
should integrate with parse too, that would be great for dialects 
(replacing chars and such).

and features to write specialized loops, like remove-each .

(indirect set mainly)

It does integrate with parse - have you tried the rewrite rules? 
More advanced stuff can be done with preprocessors like your altsyn.

No, at runtime.

apply x parse [rules]

in parse
  "<" rebcode[ append out "&lt;" ]

a: rebcode [args] [stuff]
parse dat [here: some-rule (a here)]

I am talking speed ;) Your example goes thru a rebol-style call. 
a direct call may be much faster

ANd some1 (Gabriele) suggested parse can compete with rebcode in 
its area, its a vm too.

(Gabriele) -> (Gabriele?)

(yeah, that's right)

It would be interesting to have a parse opcode, but keep in mind 
that this kind of speedup would likely be implemented in the JIT, 
when we get that. And however fast parse is, its overhead dwarfs 
that of a function call. And remember, using apply would be significantly 
faster than calling a function in the do dialect because there isn't 
any evaluator overhead.

Keep in mind that parse can be jitted too :)

No, it really can't. You could in theory build a compiler for a static 
subset of parse, but parse rules can change at runtime, even while 
they are running. They are passed by reference, remember. The reason 
you can JIT rebcode is because every code block must be supplied 
as an immediate literal and so can be considered static. If you do 
runtime modifications of the code blocks, code-as-data stuff or other 
REBOL-like tricks a JIT wouldn't really work, and certainly provide 
any speedup. Keep in mind that rebcode is a compilable subset of 
REBOL - the rest of REBOL mostly isn't compilable.

JITs like hotspot can handle such changes.

Hotspot compiles a VM that doesn't allow self-modifying code, just 
replacable code.

It can switch from native code back to bytecode if the mathod is 
changed. and from bytecode to native once something is compiled.

All you need is tracking references to a parse-rule, and signal such 
references to fall back to interpreter if rule is changed.

When Java bytecode is changed, the entire function is replaced with 
a new function with the changes. It's not changed in place.

its practically changed in place. Thats magic inside vm, adapting 
stacks etc.