World: r3wp

note, that rebcode10.zip has APPLY. see notes.txt.

Gabriele - who does low-level coding - you or Carl? :-) It already 
seems to me, that rebcode is more powerfull than initially planned, 
that is really nice :-)

Carl.

i only wrote the new assembler (print mold rebcode*)

btw, about log2, you could write:

use [w] [
	rebcode-define [
		'log2 set w word! #==>
			log (w)
			div (w) 0.6931471805599453
			.
	]
]

Gabriele - some time ago you also did interesting script - parse-rules 
or anything like that? Or was it script to make own datatypes? You 
now seem to be an expert in that regard, providing us the assembler 
part. Maybe stuff I mentioned could be added to rebol in some extent? 
Would it be worth it? :-)

compile-rules: it's a compiler for parse rules, that allows extending 
the parse dialect. i think, that some of the extensions available 
using compile-rules should eventually get into the parse dialect. 
but, parse is not high on the pri list right now, so don't hold your 
breath.

ok, thanks ....

custom datatypes: i have played with the idea a lot. however, the 
way that would be done natively is different from how you can try 
to do it in REBOL. i think custom datatypes are quite low pri right 
now too... you should ask Carl, but i guess it's more of a REBOL 
3.0 thing.

but, since custom datatypes and plugins are somewhat related, i might 
be wrong.

and plug-ins are planned anytime soon? :-)

Just asking, as I noticed them being mentioned during Carl's presentation. 
Dunno if they are priority now? :-)

i don't know what their priority is right now. but i can say that 
the sooner they are available, the better it is for RT, since then 
it is much easier to get external contributions (i.e. you don't need 
to have the C code to make improvements to REBOL). your only way 
to know their priority is to ask Carl; i think that there are more 
important things right now, tough (e.g. LNS).

back to the temp vars problem:

i found the bug that caused the infinite loop. i'll see if Carl can 
create a new build soon.

anyway, this:

f2: rebcode [] [res: (x * (y + z)) + (w * y)]

produces:

	set res x 
	set rv y 
	addd rv z 
	muld res rv 
	set rv w 
	muld rv y 
	addd res rv

which is ok with just one temp var.

but, i found an example which isn't. let me see if I can solve it...

ok, it was easy.

f: rebcode [] [res: (x + (y * z)) + (w * (y + x - (4.9 * z)))]

produces:

	set res x
	set sym5 y 
	muld sym5 z 
	addd res sym5 
	set sym3 w 
	set sym4 y 
	addd sym4 x 
	set sym6 4.9 
	muld sym6 z 
	subd sym4 sym6 
	muld sym3 sym4 
	addd res sym3

the number of variables could be reduced... but, i'm not writing 
a real compiler after all... this is just an example. :-)

Optimization exercise lef to the programmer ;-)

how can I write in rebcode: x ** y , where both x and y are decimal! 
?

ah, there's 'exp...OK :)

Seeing as I am the programmer :) ...

I gave it some thought, and realized that any solution like Gabriele's 
(paraphrased)

    use [tmp] [rebcode-define ['blah #==> ('tmp) blah]]


would not be recursion-safe. Any word you added would not have its 
context fixed by the interpreter on recursion, and so would get reused 
and trashed. This was also the case for my idea of a built-in USE 
rewrite rule that would be applied in the assembler after the userdef 
rules were done. Unless you can hack the rebcode function context 
after rewrite to enable variables added to said context during rewrite 
we are out of luck.


So, to do this kind of advanced rewriting we would have to do it 
before the rebcode function is made, rewriting the original body. 
Darn.

Oh and Gabriele, I am writing a real compiler.

Can I expect some kind of GOSUB?

Apply has been added. It works like this:

Args: result func-name args, such as:
		apply data read [http://www.rebol.com]
		apply time now []
		apply year now [true] ; /year refinement

Works also for rebcode functions:
addit: rebcode [a b c] [add a b  add a c  return a]
testit: rebcode [n /local r] [apply r addit [n 10 100]  print r]

New REBCODE release: www.rebol.net/builds/031/rebcode11.zip

Includes above, plus other changes. See the note.txt doc included 
in the zip.

Also, please tell me if the zip file  is a problem.  This zip file 
is being created by XP, not by zip, etc., so who knows if it really 
conforms to the proper standard.

I should also comment:

These rebcode releases are intended to focus on the VM and opcodes 
themselves, plus the lower level expressions ("assembly code") necessary 
to make that happen.   We are not focusing on higher level expression 
methods (e.g. compiler) at this time.  We assume that many such things 
will happen (from many sources), but for now, we need the base VM 
to be solid first.

It might be good to create a new group for discussing the higher 
level ideas.

Also note: To see the current valid opcodes and their arguments, 
type this:
      print system/internal/rebcodes

This object is actually used by the assembler.  And, many opcodes 
include comments to explain what they do.  A good reference.

Hint: try to set:  rebcode*/debug?: yes   if you are creating rewrite 
rules. (note, produces a lot of output)

I have only been discussing higher-level issues to the extent that 
they would affect the semantics of the lower level. At this point 
the only such concern I've had is the problem of adding variables 
in rewrite rules. This would be required by compilers, something 
perhaps a little too high level to consider for doing with rewrite 
rules. On the other hand, this variable addition might also be required 
by peephole optimizers, something that seems very appropriate to 
add on the level of the rewrite rules. This is, of course, up to 
you.

Carl, love the new Apply, thanks!

So, Brian - if you have any suggestion of how to improve low-level 
to make it compilable later in higher-level, just suggest! :-)

Great, I mention that ADDD and the like can take integer arguments 
in the second parameter but the syntax doesn't allow it in version 
10 (and request a change in declaration), and now in version 11 the 
opcodes don't take integer parameters any more. I hope that change 
resulted in a good speedup - it would certainly be easier to JIT.

so you think rebcode will be "compillable"?

AFAIK, ADDD (etc.) can only take decimal! arguments. it does not 
crash with integer!, but it does not work either.

What is assigned to the word argument to BRAW: A relative offset, 
an absolute offset into the block, or the word value of the label 
to be branched to?

i think, relative offset (like bra)

Gabriele, last version adding an integer to a decimal with ADDD worked 
if the integer was assigned to a variable. I mentioned it here, requested 
the syntax check reflect this for literal integers as well. This 
version integers don't work. I'm not complaining, just updating since 
I mentioned it before.

Relative offset seems to be the least useful for use with computed 
goto. With absolute offset in the block you could have each label 
word be assigned their offset as a value, and then assign those values 
to other words to be branched to later. If the offset is relative 
then you have to recompute the offset for every branch statement. 
This is quite awkward for more than one branch statement.

strange, when i fed integers by mistake i always got very strange 
results :)

i'll ask Carl if the offset is relative or absolute.

I've seen computed gotos used by threaded interpreters and that ProtoThreads 
package among other circumstances, so I'm quite interested in their 
use here.

They can be a great way to speed up state machines, implement switch 
statements and such.

(I mean C-style switch statements)