World: r3wp

Oldes, that's a tough one. If you aren't using rewrite rules it's 
easy, if tedious, to count offsets like I did above. The last code 
I posted here used a switch statement:
    set offs [14 4 0]
    pickz dest offs n
    braw dest

is sort of like switch(n). The  selection of the right offset to 
branch to can be as simple as that or as complicated as you want.

If you are using rewrite rules you can't count offsets because the 
length of your code can change with every rewrite.

Is it possible to declare the distance between two labels as data?

I still do not understand what does the braw :(

rc: rebcode[][
 seti v 2
 braw v
 probe 1
 probe 2
 probe 3
]

(sorry, on the phone, brb)

so it skips over number of the rebcode words

yes. but i dont know how to do arithmetices with labels

.

isn't this bug:

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

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.