World: r3wp

To use only one temporary variable may require a topological sort 
of the expression, if it is at all possible. I want to be able to 
generate anonymous temporaries if necessary.

(there's an infinite loop in my compiler using your example, i'll 
need to debug it later - too sleepy now ;)

but, it works removing one paren.

>> f: rebcode [] [res: x * (y + z) + (w * y)]
>> print mold second :f

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

only RV is used as a temp var... and it's always the same rv.

if you can find an example where this would not work... please let 
me know; i guess you will, since this compiler is just a quick test, 
and i didn't expect it to work this well ;)

Well finding an example is simple: Just convert to stack code and 
figure out when the stack would be used more than one deep between 
ops. That means more than one temp var. What we get for going to 
a register machine in a stack language :)


This would all be solved by a built-in USE directive with literal 
blocks that acts like USE in REBOL except only binding at rebcode 
creation time. It could be implemented as a built-in rewrite rule, 
changing the temporary variables to local variables, renaming if 
necessary. This rewrite would be done after the user-defined rewrites 
were done, but before the binding to the opcodes.


Let me think about how this could be implemented - I am late for 
a class.

rebcode 10 was released .....

Pekr, yes, rebcode docs will be forthcoming.

thanks ... the docs will be pretty comples - soooo many opcodes in-there 
:-) I just wonder, if Gabriele does only some wrappers or even C 
internal coding? :-) And if he is so good at it and RT is working 
on a low-level stuff for a while - there were few wishes to improve 
library interface and callback support. Imo it is still in versio 
like Jeff did it initially and some update which would make wrapping 
easier would be handy :-)

I have a dialect to simplify routine! writing, but I don't know if 
there is anything else planned for the library interfaces right now.

imo callback  support is weak, dunno if other languages have such 
a limit as 16 possible callbacks ... well, there is many indications 
in dll.so group. It surely will not be a priority for RT right now, 
as it simply works as a solution, but I just thought that those two 
things (dll C interface and VM assembler) could be related somehow 
...

besides that, yesterday I played part of Carl's speech, and in QA 
part I noticed something like a mention of interfacing via plug-ins, 
but I could easily misunderstood because of my "ability" to distinguish 
natively spoken English :-))

from Carl:

log2:
   log n
   div n 0.6931471805599453

Do you still want it as an opcode?

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.