World: r3wp

Brian: I know I can use to-int but I need decimal value so I'm using 
to-int to-dec. Don't know if native floor would be faster..

Probably not.

Posted to RAMBO:

A SIGN opcode would set a word to the integer -1, 0 or 1 depending 
on whether an argument is less than, equal to, or greater than 0.


sign: ["Set variable to the sign of a value (-1,0,1)" word! word!]


It would be preferable to have SIGN work with all numeric arguments, 
but you might choose to implement this as sign.i and sign.d for speed 
- either way is fine by me. The SIGN opcode, when combined with BRAB, 
would enable functionality equivalent to the BRAS proposal (#3948), 
and so would supercede it. There are many other uses as well.

; Equivalent of BRAS (RAMBO 3948):
sign a x
brab [l0 l1]
; x < 0
label l0
; x = 0
label l1
; x > 0

; Equivalent of CEILING
to-int x
sign a x
add x a

; Equivalent of COMPARE for numbers
set a x
sub a y
sign a a

Is/will be  possible to use apply on function in object! ? Following 
code does not work:

>> ctx: context [rcmul: rebcode [a][mul a 2 return a]]
>> rca: rebcode [a][apply x ctx/rcmul [a] return x]
** User Error: Syntax error: apply x ctx/rcmul [a] return x
** Near: make error! reform [msg copy/part mold/only where 50]

Not sure, we can now take the value of a word? with bind or something? 
and then apply that?

Yes, you can do this:
>> ctx: context [rcmul: rebcode [a][mul a 2 return a]]
>> myrcmul: get in ctx 'rcmul
>> rca: rebcode [a][apply x myrcmul [a] return x]
>> rca 3
== 6


But I think, Kru got a point. It would be better to be able to do 
it his way.

Geomol I thought it's possible this way, but I've got object that 
holds some values plus function for manipulating this values. So 
it's not possible to export my function to global context.

Because I've got lot of this objects (i.e. this object is oscillator 
with settings like pitch and with one rebcode function to produce 
actual value).

Right, and it's not 'nice' to export things to the global context 
like that. We should have it your way! Write it in "RT Q&A".

i thought we have some sort if binding in rebcode now. then it would 
be like

   rebcode[][ set word 'rcmul bind word  ctx  setw x word  apply x [..] 
   ]
but not soure if its really there, and about syntax.

oh

Volker, there's no 'bind in system/internal/rebcodes

Is 1.3.50 current, or is there somthing more new?

1.3.51 28-Oct

I've got 1.3.51

Why not doing it this way? :
>> ctx: context [b: 4 rcmul: rebcode [a][mul a b return a]]
>> rca: rebcode [a] bind [apply x rcmul [a] return x] ctx
>> rca 2
== 8
>> ctx/b: 3
== 3
>> rca 2
== 6

DiceC thanks, that should solve my problem. I'm not strong at binding.

DideC, neat! :-)

There is some reasons that makes relative jmp better than absolute 
ones in rebcode? In other words I am asking why bra uses relative 
jmp.  I think that absolute jmp are more easy to handle, at least 
for me.

Romano, not that I would normally be defending relative jump (look 
at the group history :) ), but when you have to specify the offsets 
as literal numbers, relative offsets are more useful. Most of the 
time branches are used for control flow on a local level - branches 
only work within the same code block and most code blocks aren't 
very large. If you have relative branches, you can add instructions 
before the affected area without having to recount all of your branch 
statements, and you can add code snippets into code without having 
to add labels. When you use absolute branches that doesn't work so 
well. Of course there is no difference when you are branching to 
labels because either way the assembler would be doing the counting.

Absolute offsets are more useful when doing calculated branches, 
but right now rebcode doesn't do those.

There is something in the rebcode docs about a special case behavior 
for BRAB that would enable calculated branches, but that special 
case hasn't been implemented yet. I have just made a RAMBO request 
that this behavior be implemented, so we'll see how that goes.

Gabriele, Gregg, my initial comments on the rebcode documentation 
has been sent to Feedback. If anyone would like them posted here 
as well, please say so.

BrianH, I'm interested

With that kind of overwhelming interest I must respond :)

Here are some initial comments on the recently posted rebcode documentation 
draft:

- It has been suggested on the list that since the assembler's rewrite 
engine is a mezzanine, it might not be included in the final version, 
in favor of (to promote?) user-made rewrite engines. If not, you 
would need to change the documentation to match, especially section 
1.4.

- It needs to be made clear somewhere in the initial description 
of the rebcode dialect that rebcode is a statement-based language, 
not an expression-based language like the do dialect. Opcodes perform 
actions, but don't return anything per-se. The 2.1 or 2.3 sections 
would be a good place for this explanation to be.

- In the "Branches are always relative" note at the end of 2.6, there 
is a sentence "The branches are always relative to the current block." 
that could be removed. The whole note should probably be renamed 
to "Branches are always local" because the note doesn't really cover 
that they are also relative. Also the phrase "use a branch opcode 
to" could be replaced with "branch to" and be less awkward.

- A common mistake in specifying literal branch offsets is to miscalculate 
what location the offsets are relative to. This mistake would be 
less likely if the third paragraph of 2.8 were changed to "The argument 
to the branch opcodes is an integer value, representing how much 
of an offset you want the branch to perform. Branch offsets are always 
relative to the location after the branch statement, not the absolute 
offset within the block. Positive values branch forward; negative, 
backward. The branch target must always fall within the current code 
block." as this is the actual branch behavior (and more clear).

- The sentence in 2.8 "The brab opcode allows computed branch offsets 
to be created." isn't really true right now, at least in any practical 
way. The current behavior is more like "The brab opcode allows you 
to branch to an offset selected at runtime by an index.".

- The paragraph at the end of 2.8 "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." would be a good idea to be implemented 
(I've submitted it to RAMBO), but is rather awkwardly phrased. This 
could be rephrased once the behavior is implemented, or left alone 
if you don't want most rebcode users to use this behavior.

- In section 2.9, the sentence "Result then refers to the value returned 
from the function." may be better said as "The word result is then 
assigned the value returned from the function.".

- 4.1.*: The phrasing of many of these entries is awkward. Also, 
remember that opcodes don't return anything, they modify operands.

- 4.1.1: I'm not sure "integral" means "the integer part of" as it 
is used here; the word may be more related to integrate than integer.

- 4.1.4: Lowercase the "Tail" word to be consistent. Otherwise, well 
phrased.

- 4.1.5: The descriptions of change, copy and insert don't describe 
how their amount parameter is used. You could describe change as 
"Changes part of a series at the current position to that part of 
a value (-1 for the whole value).", copy as "Set the operand to a 
partial copy of the series (-1 for all) from the current position.", 
and insert as "Inserts part of one series (-1 for all) into another 
at the current position.". Or, you could provide further explanation 
in some new 2.* section.

- 4.1.6: In the description of index?, change "Returns the" to "Set 
the operand to".

- 4.1.7: Does not reflect the renaming of the opcode get to getw 
and the addition of setw. Also, instances of "Result modified" should 
be changed to "Set result" or "Set operand to result".
- 4.3.3: The braw opcode has been removed.

so, now it's brawless.

Yeah, well after all that work I did on that OFFSET directive to 
make braw useful, I feel a little burnt by braw :)

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!