World: r3wp

Hopefully they actually implement something like that "special case" 
of brab.

BrianH: "If you have relative branches, you can add instructions 
before the affected area without having to recount all of your branch 
statements"

Yes, only branches which are affected by the addition. Not a great 
advantage from my pov, because with relative branches is a little 
more complex to establish what branches are affected and what branches 
are not affected.


and you can add code snippets into code without having to add labels.
I do not understand what you mean with this.

OK, here's how you figure that out. You have the branch statement, 
and the branch target. Now you have two possibilities here: The target 
is before the branch or it's after it. If the target is before the 
branch then you can add instructions before the target or after the 
branch, but not between them, and not have to recount your offsets. 
If the target is after the branch then you can add instructions before 
the branch or after the target, but not between them, and not have 
to recount your offsets. The trick here is that if the number of 
instructions between the branch and its target don't change, then 
you can do whatever you want with the instructions around that group 
and not care.

As for "and you can add code snippets into code without having to 
add labels", imagine that you are generating your rebcode, or copy-paste 
coding, rather than hand-writing every line every time. Now imagine 
that there are branches in the code snippet you are putting into 
your code unchanged. If you use labels as branch targets, you may 
end up accidently reusing some label name that already exists in 
the block and the assembler will complain. To avoid that you can 
branch to offsets specified as literal numbers. You get these numbers 
by counting the instructions between the branch and the target yourself. 
This may seem like a lot of work for code that you have to write 
every time, but it is not too much work to put into a tested snippet 
of code that will be reused as is, over and over again. And if you 
have relative branches, you only need to consider how far apart instructions 
are within the snippet, rather than recalculating those offsets depending 
on what position the entire snippet has in the block you are inserting 
it into.

Remember that if you are programming with snippets, then every change 
you make to that snippet would need to be tested. If that change 
is made by a processor, then you need to test the processor. If the 
change is made by hand, then the changed code will need to be verified 
again by hand. This all would make rebcode-generating dialects more 
difficult to implement. And rebcode, generated or written, needs 
a lot of testing because you can easily crash REBOL with erroneous 
rebcode.

Rebcode is a lot higher on the shoot-yourself-in-the-foot capability 
scale than the REBOL do dialect. :)

graph-layout: I won't have the time to get deeper into rebcode in 
the moment. So, here is a request, for something that gives a nice 
demo: I have the old graph-layout code, which uses the TouchGraph 
idea. Anyone interested to port it to rebcode and see howmany nodes 
we can handle?

yes :)

Ok, you got the code?

No. or lost.

Ok, I send it to you. I have serveral versions, one using faces, 
one using draw (but has problems with layout that doesn't converge). 
IMO a version using draw and rebcode would be nice.

the code is then public? since i can then develop public too.

Send to Gmail account.

Yep, no problem.

thanks

BrianH: my argument is: 


case 1) given a block of absolute jump [ 15 36 40 46] and 2 statement 
added at line 37 i can adjust the block easy,


case2 ) given a block of relative jump [-10 -5 15 30] and 2 statement 
added at line 37 i must know also the starting  jump position,  calc 
the new position of jump after the addition of code, calc (directly 
or indirectly) the absolute adresses of jumps ,  make the same work 
for case 1, and transform back jumps in relatives ones. A lot of 
work and a more information needed.

maybe relative addresses are shorter than absolute ones? absolutes 
need 32/64bit, relatives 8.

Thanks Brian!

Any time Gregg! In particular, every time changes are made to the 
engine or docs :)

Romano, I feel your pain. If you look at the history in this group, 
you will find that I have gone into great detail about how much I 
feel your pain :(

But given your cases here, keep in mind that the only instruction 
now that takes a block of offsets is BRAB. As I have said above, 
BRAB with relative jumps means that it is only practical to use an 
offset block from a single branch statement. Branching to a block 
referenced by a word is only practical for rather obscure circumatances 
(for instance a multistate machine). So for most code using brab 
the offset block will be placed right there in the statement., so 
you will definitely know the starting position. But your second case 
is a little off, because with relative jumps, you don't need to know 
the absolute position of anything.


Assuming a branch offset block like the one in your second case, 
the relevant section of the code block you are using starts with 
the beginning position of the first target statement and ends with 
the beginning position of the last target statement. Branch offsets 
are calculated relative to the end of the branch statement, a position 
we will call the source. With relative jumps, you don't have to take 
into account the absolute position of the end of the branch statement, 
you just need to count the positions between the source source and 
the target. You don't need to know that any added instructions are 
on line 37 (a meaningless concept in rebcode because lines are ignored), 
you only need to tell whether the added instructions are in between 
the source and the target, and then increase the offsets on that 
side of the branch accordingly.


For most branches you will probably be better off with labels and 
let the assembler do the work. But for code snippets, what I often 
do is just do the intiial writing with labels, put the code in a 
rebcode block and let the assembler do the offset calculations. Then 
I copy the fixed up code, remove any label statements and adjust 
affected offsets by two for every removed label statement. Let the 
assembler do most of the work.

(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 ...