AltME groups: search

You can't sub a string. That's why I added the CMP above. Less than 
or greater than doesn't make sense for blocks.

Ah, get it. i thought compare takes two chars, and we have to loop. 
as a loop returning -1,0,1 it makes sense.

but i am not sure about this special case. sometimes i want to know 
where the difference occoured  and such things. So i prefer a selfmade 
loop, with rebcode. Except it turns out string-comparisons are very 
common.

If you expect the comparison to be common, why not make a subroutine 
and apply it or compose it in when needed? Not everything has to 
be an opcode, and the difference will be slight after the JIT is 
implemented.

because it is common in small loops: string-comparison, binary search. 
adds overhead in interpreter. is hard to detect for jit (its jit, 
not a heavy global optimizer).

Fair enough. The string cmp would be a good idea to suggest to RAMBO, 
although I would suggest it be renamed to compare.

Which ones do you test?
>> f: rebcode [a b /loca r] [apply r ** [a b] print r]
>> f 3 5
** Script Error: Out of range or past end

I kind-of expected bras to be rejected. There was a workaround using 
min and brab, slower but doable. This is why I put "Undetermined" 
as the priority when I submitted it. Compare seemed like a good idea 
though.

I've done it dozens of times during my testing. I should really put 
together a list of rebcode sequences that can crash REBOL.

ok, good to know for me rebcode can be "insecure" in a sense that 
you can kill the process ...

JVM and CLR VMs do a lot of testing of their bytecode sequences before 
execution, as part of their security testing. Until someone makes 
a type-inferencer for rebcode, it won't be safe to use without manually 
reviewing every function before use, or only using rebcode generated 
by trusted compilers. It is much like machine code in that way.

well, still have to have occassionally crashing rebcode, than libraries, 
which will always be regarded a security flaw ...

I haven't been able to come up with a way to exploit these crashes 
(nor am I likely able to do so), but crashing the process repeatedly 
can be a good denial-of-service technique. Type flow analysis is 
a must for rebcode, so be extra careful with your data type testing!

To me the BRAB example in the rebcode docs in section 2.8 is quite 
unclear. "The brab opcode allows computed branch offsets to be created". 
You can say the same about BRA, BRAF and BRAT as well. :-)


I have no idea what this opcode does, except that it looks vaguely 
similar to a SWITCH so it would be doing multiple branches somehow. 
It would have helped to see output results from the code and to have 
a better initial explanation on how to use BRA with integer indexes 
and an explanation of the B in BRAB. Do you agree?

BRAB branches to an offset selected from a block of offsets by a 
0-based index value. It can be used to implement C-like switch statements. 
The B at the end of BRAB means block.

Like with the other branches, if you specify the branch targets by 
label the assembler converts each target label into a numeric offset. 
This is called the fixup pass of the assembler. The assembler only 
fixes up branch labels for BRAB if the block is placed as an immediate 
literal in the statement.

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.

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?

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

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!

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

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.

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.

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

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

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

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

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

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

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.

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.

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.

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

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.

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?

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.

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.

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)

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.

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.

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.

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.

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

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.

this looks like a bug to me:

>> o1: context [a: 0 rc: rebcode [x][set a x]]
>> o1/rc 3
>> ? o1
O1 is an object of value:
   a               integer!  3
   rc              rebcode!  [x]

>> o2: make o1 []
>> o2/rc 5
>> ? o2
O2 is an object of value:
   a               integer!  3
   rc              rebcode!  [x]

>> ? o1
O1 is an object of value:
   a               integer!  5
   rc              rebcode!  [x]

questions we need to get an answer for, especially from BrianH as 
a supplier of #3947:

; Index of non-equal, 1-based, assumes indexes within bounds
length? x a
length? y b
gt.i x y
ift [set.i x y]
repeat i x [
    pick x a i
    pick y b i
    eq.i x y
    breakf
]
; i = first non-equal index

to-pairs function returns some a lot of negative pair! , why is the 
image shifted?

about building a native compiler from an interpeter.

ech 10MB of download just to read a simple text file, I'm not going 
to read it today.

2 ** exponent:

set a 2.0
log-e a
mul.d a exponent
exp a

or you can use set a 0.693147180559945 to save one instruction

>> x: rebcode [exponent][set a 2.0 log-e a mul.d a exponent exp a 
return a] x 3.0
== 8.0

>> x: rebcode [exponent][mul.d exponent 0.693147180559945 exp exponent 
return exponent] x 3.0
== 7.99999999999999

that's quite a lot...

looks neat, but I think people use more than 120 triangles in their 
own demos. :-) is it open or flexible enough to be used as a general 
engine?

I think it would be fun to have a little engine. I'm thinking something 
like:

view 3d-layout [sphere 50 red .... ] etc. :-)

This is also how Maya is built. A powerful 3D engine and a comprehensive 
programming language which builds the editor. A little like Emacs.

a pity pairs don't have a third dimension... otherwise you'd have 
to use tuples except it would be confusing with positions vs. colours.

kru, yes I think dialects would be ideal for describing a 3D environment, 
at least the parts that are not related to motion perhaps.

And then we do a 3d-desktop? :)

Yes. Something like this atomic modells. Each ball is a site and 
you can move along the connections :)

Just a small update: I've fixed matrix inversion so it's possible 
to move camera now. It's not possible to rotate camera but I'm working 
on it.

Every event has a time (event/time), so this could be worked around.

Kru: I don't know, write it to Rambo as a wish if you wish:)

You can use 'third, 'get and 'set to turn objects into blocks. only 
from the rebol-side, but maybe it helps a bit.

Kru, you can use apply in or apply bind to get a word bound to the 
object field, and then use setw and getw to get at the values.

Continuing from SDK group: I noticed that cyphre thinks pixel writing 
and reading can be a bottleneck in the current rebcode implementation, 
which is why the native convolve functions in rebol/view 1.3.2 are 
much faster than the rebcode version demonstrated earlier.

By providing ways to read and write RGBA information directly without 
needing to extract and combine them first, rebcode could be faster 
at per-pixel operations.

Any thoughts on how to do this?

I got an email from Carl at one point regarding this issue. I asked 
to have poking of tuples in rebcode. Carl wrote:

Regarding below, tuple poke not supported on images.
But, perhaps 
it makes sense to add that, eh?


As I also see it, adding support for tuple datatype from within rebcode 
is a good solution. Carl is aware of it, it seems, so just *poke* 
him once more and ask for that. It should also work with PICK of 
course (reading pixels).

I'm a bit in two minds about this. Reading is done with PICK, but 
it'll return an integer. So how to make it return a tuple? Something 
like:
pick.tuple result img 1

Not so good, eh? Maybe we need a TO-TUPLE command in rebcode. And 
how will it influence performance? Maybe it isn't such a great idea 
to add support for tuples to rebcode!?

hmm, 'to-tuple is not bad. it's just a graphical interpretation of 
bytes in memory. there's no difference between 16777215 and 255.255.255 
. It's just parser's job.

shouldn't it be an op-code? like TUPLE-PICK, only a slightly less 
goofy name :-)

Hmm, now I think about it once more, maybe a special PICK isn't needed. 
The internal representation of values, whether they are seen as integers 
or tuples, can be the same. If we name each of the components of 
a 4 part tuple red, green, blue and alpha, the following holds:

integer = (alpha * (2 ** 24)) + (red * (2 ** 16)) + (green * (2 ** 
8)) + blue

What we need, is the ability to tell values as tuples as well as 
integers. Internal they are the same. I would like to be able to 
do this:
poke img 1 16843009
poke img 1 1.1.1.1
pick result img 1
eq.i result 16843009
eq.i result 1.1.1.1

But again, it might hit performance too much, because the parser 
needs to check, if an integer is written as an integer or as a tuple.

I've made a test of a voxel landscape engine in rebcode. As I did 
it on my Mac, it's written in the version of rebcode found in the 
version 1.3.50 of REBOL/View from around Oct-2005. I haven't tested 
it with the Windows version of View, but I guess, it should work 
with that same version 1.3.50. I first did a plain REBOL version 
and got a framerate of around 3-4 fps (frames pr. second). With the 
rebcode version, I get around 20 fps. The script is found here: http://home.tiscali.dk/john.niclasen/voxel/NicomVoxel.r


I've also made a snapshot here: http://home.tiscali.dk/john.niclasen/voxel/snapshot.png

In case someone is interested in trying the script out, you can move 
around with w, s, a and d.

I get a bug:

>> do http://home.tiscali.dk/john.niclasen/voxel/NicomVoxel.r
connecting to: home.tiscali.dk
Script: "NicomVoxel" (2-Apr-2006)
** User Error: Rebcode syntax error:
mul idx cZ
add idx cX
pickz OldY heightmap idx
** Near: make error! reform [msg copy/part mold/only where 50]

That one have a newer version of rebcode, use the old one.

For Mac, use: http://www.rebol.net/builds/024/rebview1350024.tar.gz

For Windows, I guess this will work: http://www.rebol.net/builds/031/rebview1350031.exe

ok, I get 20 fps on a 1.2 GHz G4 Mac.

The snapshot may have been done with a slightly different version. 
I play with the colours.

strangly it seems I'm the only one with this problem. I've talked 
a lot about how slow SHOW is, but it seems to be unique to this PC

Use w, s, a and d to move around.