World: r3wp

(sorry, that could have used a little more proofreading)

maybe relative addresses are shorter than absolute ones? absolutes 
need 32/64bit, relatives 8
 rebcode use 32 bit for relative jumps

Brianh: tell me how to adjust the brab block [-10 -5 15 30] knowing 
that the statement "add a 1" has been added at index 37 (you do no 
like "line") in the same block in which brab appears. You do not 
know the absolute position of the brab block.

Is the index 37 position relative to the beginning of the entire 
code block that contains the brab statement, or relative to the statement 
targeted by the -10 offset in your brab offset block? The "affected 
area" of your brab statement is the 40 instructions beginning with 
the one pointed to by the -10 and ending with that pointed to by 
the 30. This is also referred to as a "basic block". When your branches 
are relative, this area is the one that you should be concerned with. 
If you are counting your insertion index relative to the affected 
area then the only offset affected by the insertion would be the 
30, which would need to be changed to 33.


If you are counting your index of 37 as an absolute offset (actually, 
relative to the beginning of the code block that contains the branch 
statement), then you need to subtract the absolute offset of the 
branch statement to convert to the offset scale that matters, that 
relative to the branch statement. Coincidently, that is exactly the 
calculation performed by the label fixup phase of the assembler. 
Because of this I tend to suggest that when you are programming based 
on the whole code block, typical of programming-by-hand, that you 
use label statements and branch to them.


When you use literal offsets you have to consider the range of instructions 
from the branch to the target as being one entity, a "basic block". 
When inserting instructions into a basic block, all you need to consider 
is how it affects that segment of code. These code segments are usually 
developed and tested independently, and then dropped whole into the 
greater stream of code without much change. Programming by stringing 
together a set of these basic blocks (or code snippets) is often 
what code-generating dialect processor (or "compiler") does.

An optimizer does just the opposite: It converts the literal offset 
to a kind of virtual label statement (the difference being that the 
virtual one takes no space in the code); then after code insertions 
or deletes have happened, it changes the offsets to their new values, 
just like rerunning the fixup phase of the assembler. Of course optimizations 
like this can get a little more complicated when you have branch 
targets calculated at runtime - this was probably why they added 
BRAB and removed BRAW in the recent release, replacing general branch 
calculations with a simple lookup table.

As for whether the relative offsets are more efficient than absolute, 
that is only true of actual machine code, and then maybe only on 
older processors without an instruction cache. What we are calling 
an absolute offset here isn't a memory address like it is in machine 
code, it is really just an offset relative to the beginning of the 
code block, rather than the location of the branch statement. I think 
that the reason Carl chose offsets relative to the location of the 
branch statement is that he decided to only implement one branch 
method in the VM, and this method is more friendly to generated code 
(or maybe that was just luck).

Offsets relative to a fixed location are the (currently theoretical) 
"special case" of the BRAB statement. See RAMBO 3953 for details.

that case is no more theoretical, see new build. however, i don't 
think it has been tested much so far.

so, the first argument of brab can now be either a literal block 
(with labels or integers), or a label. the second arg can only be 
a word referring to an integer.

Is there some changelog for 1.3.52 ?

yes, source, diff :-)

The great rename is here! Woohoo!

ah, the dots

so it's good to cheat in surveys...

I didn't cheat.

I don't know who did, but opinions here were different from the survey

The dots were one of my favorite choices.

OK I know it's a dialect, not REBOL, but there is not a single word 
in REBOL that uses dot. Decimals and tupples use them, but not words.

You can use dots in words.

Most don't.

I can live with dots but I don't like it, looks really un-REBOLish

Quick to type though, at least compared to - on my keyboard.

So, why hasn't the syntax signiature of brab changed to match the 
new behavior? In theory, we can now specify a literal integer at 
the first position, as that is what the label fixup changes brab 
to in the special case. The syntax check doesn't allow it though, 
because it still looks for word! or block! only.

; BRAB should be like this
brab: ["Branch block table" block! | word! | integer! word!]

Hm this is not directly related to ".",  but now I realize I've got 
some 1000 lines of rebcode to rewrite :)

Search and replace :)

:)

Brian - it was not about "qick to type" ;-) If so, we should replace 
path char with dots too ...

I agree with Kru that once again probably the poll was only informative 
and the voice of most - ignored ...

Well, the dot and dash versions were really arbitrary between them. 
We couldn't do paths and the no-change and no-seperator choices had 
significant negatives.

At least the dot being unlikely in normal rebol code makes these 
opcodes more useful in rewrite rules, since you will know what to 
not look for.

I suggested the dash, but the dot is just as good to me.

And anyway, REBOL syntax is designed to be quick to type. That is 
why we use - instead of _ and [ ] instead of { } like other languages.

but why not -

As Cyphre said: because dot looks more like assembler ;)

never mind, I will probably never write rebcode leve code anyway 
:-)

It is a good visual reminder of the different semantic model, this 
is true...

Well, I don't write View code. We all have our strengths :)

And on that note, where's the Core version of the new build?

Testing: The new brab works. The eq.i opcode still works on logic 
and datatype values as well.

For those with a lot of rebcode already, there will probably be a 
conversion tool to update your scripts available shortly.

I can live with dots but I don't like it, looks really un-REBOLish

 -- That's by design. The opcode names are not human friendly either; 
 also by design. The idea being that rebcode is *not* REBOL, and having 
 it look more like ASM makes you more aware of that. There will probably 
 also be a separate style guide for rebcode at some point.

Kru: we have a script that does the conversion automatically. Ask 
Ladislav.

(ah, i see Gregg told you already ;)

Gabriele: thanks but I've already rewrote most of my code yesterday. 
I don't know your conversion script but I've had different scripts 
using 1.30.50, .51, .52 and even old 1.4 alphas so does your script 
cover all different syntaxes or just the latest one?

only   mul -> mul.i, muld -> mul.d and so on. i.e. latest.

And rewriting scripts manually was great opportunity to otimize them 
to (and sometimes by factor of two, so it was for good :))

:-)

otimize-optimize

What's the problem with dot? I was not voting, but must say I like 
dot. At least it looks differently from variable names, where I use 
- and _ chars.