World: r3wp

is 4 "print 1"?

Yes, an offset of 4 takes you to the beginning of the print 1 statement. 
Branch offsets are calculated relative to the point immediately after 
the branch statement.

so that means each line of code is an offset of 2, or is it each 
element in the rebcode block?

Negative offsets take you back.
bra -2

takes you to the beginning of the bra -2 statement, an endless loop.

Each element in the code block.

I see... I think there should be something more clear about how the 
index works.

You can also reference the block of offsets through a word. Labels 
are not converted then - you must use numeric offsets that you count 
by hand (or in a compiler). Since these offsets are relative to the 
end of the branch statement, this block is only useful in one location. 
Also, when the rewrite phase comes back and they start using rewrite 
rules again, those hand-calculated offsets will likely be wrong. 
In theory, this could be used to implement a multi-state machine, 
but that kind of thing is deep magic that you should be doing with 
the parse engine anyways. It is theoretically possible to fill the 
block at runtime, which would technically be a computed branch, but 
this is so slow, awkward and unnecessary as to be ridiculous, especially 
for a branch block that can only be used from one location.

True computed branches require the use of the BRAW opcode. Of course, 
this opcode was removed from the engine in the latest revision and 
is not mentioned in the docs, so you are out of luck.

The index works like the index in pickz and pokez - that's not hard 
to understand. The real thing they need to explain better is how 
they count the offsets.

Henrik, they actually do a good job at explaining what the index 
is for:

The first argument to the opcode is normally a block, and the second 
is a zero-based index into that block. The value at that position 
is fetched and assumed to be the integer offset for the branch.

Now all they need to do is replace the word "computed" with "indexed".

Whoah, wait a second! Check this:

There is also a special case of operation. If the block argument 
to BRAB is an integer (created from a label), then the branch is 
made to that relative location plus the value of the index argument.
Now that's a computed branch!

But the current BRAB opcode doesn't work that way. Is this paragraph 
in error, or a sign of things to come?

I guess its an assembler-feature? it adjust the target-offsets?

soyou can branch relative to a fixed different location? Makes that 
sense?

But the syntax of BRAB doesn't allow this kind of thing (unless I'm 
reading the paragraph wrong). The block argument is type-checked 
to word! or block!, not integer!

The fixup pass doesn't currently fixup labels passed to BRAB unless 
they are in a block, and then that follows the normal behavior, not 
this "special case" behavior.

If it worked like the paragraph says, it would allow you to branch 
to a location relative to a fixed point, not the point of origin. 
This would effectively be my requested absolute branch!

Seems so. Where is the latest "release"?

Same place the rest of the latest releases are.
http://www.rebol.net/builds/031/?C=M;O=D

Isn't it shame, that the rewrite function from rebcode* context with 
the userdef-rule is missing in the latest rebcode?

I already found it usefull, here is an example: http://box.lebeda.ws/~hmm/rebol/rc_bunky7.r

As far as I can tell, it's just missing for now. If things go the 
way they have been, it'll be even better when it comes back.

I think, REBCODE will be great for teaching won't it?

Several of my suggestions and comments have been intended to make 
rebcode easier to learn. Easier to use is a side effect.

Porting knut to rebcode? :)

what is knut?

Typo, Knuth. Wrote some legendary programmingbooks, AFAIK he used 
some kind of assembler for examples. :)

Mix

It might be desirable to find out if any feature of his assembler 
is missing. Volunteers?

I don't have the Knuth books, but there is a port of Mix to the .NET 
CLR that I've been meaning to look at.

Does anyone know if Mix supports branches to addresses? Rebcode just 
branches to relative offsets.

see http://sunburn.stanford.edu/~knuth/mmix.html

Technically Mix was the virtual machine, Mixal was its assembler.

It has loads of things for i/o to devices like paper tape....I think 
rebcode could assume that happens as the mezznine level.

i and o could be series parameters

Oldes: the rewriting engine is mezzanine, so it can be easily added 
back by users. i will take care of releasing a script containing 
it as soon as we have an official version out.

so official version will not contain rewriting engine?

that's not decided yet, but probably not.

was it regarded being way too much high-level or so? Or inflexible, 
so that other ppl might find different way of how to aproach this?

the main thing is, that the details need to be discussed more (i.e. 
the grammar for the rules dialect, and things like this).

ok, thanks ...

is there some decimal FLOOR opcode in rebcode, or should I use [to-int 
val to-dec val] instead? Would be FLOOR a good addition?

FLOOR: ROUND can be adapted to Rebcode, but only partially - some 
datatypes aren't available yet, and I have got a newer ROUND version 
- better suited for Rebcodization

I don't need whole ROUND functionality, right now just FLOOR is OK 
for me (but OTOH, ROUND is very useful).

The to-int opcode is equivalent to floor, at least the round-down-to-0 
version of floor. Ceiling can be done by adding 1 (or subtracting 
if the argument is negative).

I did some test with integer conversions and found, that using rebcode 
is 3x faster than using struct! :)

But will rather wait a little bit before making more complex rebcodes, 
it would be good to have some place for rebcode scripts

So they will all be where we can find them when we have to change 
their opcodes after the great rename?

grand rename? :-) it will happen soon, no?

one more link to MMIX: http://sunburn.stanford.edu/~knuth/fasc1.ps.gz

Petr, they say the next version.