World: r3wp

and the rebcode-portions should be a small part of the programm. 
And i guess often generated by dialects. which will add checks on 
their own, which is why we have this range-checks now (IMO)

Well yes, I want to make a very smart compiler as much as the next 
guy, but still I like the invalid-as-noop behavior that many of these 
opcodes have, that all of them should have.

At least invalid-as-error would do, rather than invalid-as-crash.

Heck, in debug mode I would like all of the opcodes to act as invalid-as-error.

hmm.. does IF work?

r: rebcode [] [
  set a -1
  lt a 0
  either [return a][return 0]
] ; works

r: rebcode [] [
  set a -1
  lt a 0
  if [return a]
] ; syntax error

ift, iff (it-true, if-false)

(why not if, unless?)

ah, silly me. knew I shouldn't have read the docs :-)

Maybe they use ift, iff to empharize that they don't work like REBOL 
if, unless, that they operate on condition codes?

But that is true for pick and such true. i mean different args but 
same name. maybe saves typing?

Could be an assembly thing :)

brat and braf are like that

And they came first - the inner block thing came later.

How do I break out of a loop? This won't work:
until [
eq a 0
ift [break]
...
]

Break will exit an 'until:
    until [ break 1 = 4]  ;; does not loop forever.
Have you redefined 'break somehow

this looks like a special case

Sunanda, I'm talking rebcode! Isn't your example non-rebcode?

G: try until [eq a 0 braf 1 break ...]

Whoops!! Sorry!

Ladislav, thanks! That did the job.

rebcode now seems to be regarded an alpha version. Initial release 
contained some fine docs, not included with later experimental releases. 
Will new extended docs come?

Personal tought on REBCODE: "sniiiiiiiiiiiiiiiiiiiiiiiiiiiif don't 
toutch my rebol it looks like ASM sniiiiiiiiiiiif my poor reeeeeeeeeeeeeeeeboooooooooooool 
is all broken  :
                           set i 1
		eq i 1
		braf fail
		brat continue
		print "Should not print!"
		label continue
Sniiiiiiiiiiiiiiiiif "

but performances are great ...

With rebcode we loose on of his key feature the simplicity ... But 
for some tasks really precise that needs high perfs it's great to 
have such a tool . I don't kno yet if i ill use it every day...

you surely shouldn't

I like the brat and barf instructions :-)

but it looks not like rebol anymore  ...

the fun is, that it is REBOL. Have you seen the Alien Dialect?

I still think it's pretty simple, by assembler standards. Have you 
seen x86 assembler?

Urgh

In rebcode, every instruction has just one addressing mode, does 
just one thing. Count your blessings when you can.

Yeah i do a lot of asmx86 but ... I don't like that even if you get 
a close controle on what you are doing

shadwolf - the nice thing is, that for specific domain, you can create 
your own sub-language using parse and let it generate rebcode for 
you :-)

For some kinds of coding I would actually find rebcode to be a more 
comfortable dialect. For instance, you don't have to worry about 
whether someone has redefined add.

shadwolf - really no reason to use it on a daily basis, but cool 
to have for fast tasks - without it real-time image manipulation 
in rebol was impossible for e.g.!

At least in this case, you can count on any crashes or security holes 
being your fault instead of someone else's.

Kaj, I have found myself amost writing brat and barf many times already. 
I guess my inner child has a dirty mind :)

yea i know the complain message (1st one ) what for joking  ^^

things like list sorting in widgets like table or listview in rebgui 
could profit form rebcode optimisation

On the note of people redefining stuff out from under you, here's 
a quick redefine that can make the user-defined rewrite rules a little 
safer:

rebcode: func [
    "Create and return a rebcode VM function."
    args [block!] body [block!]
    /rewrite rules [block!]
][
    either rewrite [
        rewrite: tail rebcode*/userdef-rule
        rebcode-define rules
        make rebcode! args body
        clear rewrite
    ] [
        make rebcode! args body
    ]
]

It uses internal features, and so may have to be adjusted features 
as the assembler is refined.

Sorry, it uses internal features, and so may have to be adjusted 
as the assembler is refined.

Whoops, slight adjustment needed :(

rebcode: func [
    "Create and return a rebcode VM function."
    args [block!] body [block!]
    /rewrite rules [block!]
][
    either rewrite [
        rewrite: tail rebcode*/userdef-rule
        rebcode-define rules
        body: make rebcode! args body
        clear rewrite
        :body
    ] [
        make rebcode! args body
    ]
]

Of course you can put the rewrite part in a different function and 
save the compare/either if you want.

Another alternate syntax:

find-last-other: rebcode[s c /local c2 eq? f] probe altsyn [
 s: tail back
 while[ 
  c2: pick s 1 eq c 
  eq?: gett
  f: gett ift[ head? s f: gett not ] sett f
 ] [
  s: back
 ] 
 sett eq? either [return none][return s] 
]

OK Volker, what would that code mean in REBOL do or rebcode dialects? 
I'm having a little trouble getting it. Translate!

Is it equivalent to (indented for my clarity)


find-last-other: rebcode [s [block!] c [integer!] /local c2 eq f] 
[
    tail s
    back s
    while [
        pick c2 s 1
        eq c c2
        gett eq?
        gett f
        ift [
            head? s
            gett f
            not f
        ]
        sett f
    ] [
        back s
    ]
    sett eq?
    either [return none] [return s]
]

Please look into latest Blog article, which is rebcode related. RT 
invites us for last round of suggestions, as after the release, another 
suggestions would have to wait several months ....

On that note, a request: Please integrate the HERE (or OFFSET, you 
decide) directive I requested, RAMBO 3924. This will make BRAW useful 
for handwritten code; right now BRAW is only practical for compiler-generated 
code with no user-defined rewrite rules, because of the offset calculations 
required.

not sure if we should not use different Chnnel? Which one, as we 
will chat here, our request will scroll-off ....