World: r3wp

Well, I don't want to be a jerk, so I'm not complaining. Gabriele 
does a great job and even lurks around here when he isn't being vocal. 
We came up with some suggestions and tried reasonable means of getting 
them to the attention of the people concerned. I'm not taking the 
lack of feedback as a bad sign - these are busy people, as are we 
all. If it takes too long to find out whether they have heard us, 
I'll just summarize our suggestions in a post to feedback.

Brian we appreciate your comments, and your summary was posted to 
Carl. You will know soon enough what gets adopted.

yes, Jaime, I can understand it, but from the Brian's answer, you 
can consciously feel, that folks here would deserve some feedback. 
RT Q&A channel stopped working as promissed, folks put their requests 
in rebcode, RT Q&A, Rebol Enhancements group, RAMBO, just to be sure 
they are noticed. So - if RT monitors the situation here directly, 
or via Gabriele the "proxy", then folks here should receive some 
answers imo ... I still hope they will? :-)

ah, posted without reading previous post, sorry, was not neccessary 
then ...

Jamie, Yay!

Petr: I guess that there were not enough questions for this wednesday 
so Carl skipped it. (Just one, from you, and you always ask questions 
anyway. ;)

so we have Doc Friday and Questions Wednesday now? :-)

What would be the best way to implement switch like function in rebcode 
(with many cases - encoding/decoding table)

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 .