World: r3wp

is there any particular design you are going for yet? as in when 
we can expect to see a fixed feature set?

Instruction set redesigned for best performance. That is #1 goal, 
not the look of the opcodes.

Floating point has now been added, as well as quick access to normal 
math lib funcs (sine, log, etc.)

Carl - that is fantastic ... I am just curious what was the reason 
we got rebcode? We talked about VM for years and suddenly it is here. 
Working with pixels is fast now :-) Is it just that you really enjoyed 
your vacation or is there any customer wish behind it? :-)

The problem now is that the VM is getting close to optimal, which 
is making it very difficult to deal with the CPU oddities like pipeline 
and nonpredicted branch flushes, etc.

Hi Pekr: true reason is the move to better support OSX, which is 
on PPC. I wanted a VM so people could make faster funcs but without 
problems on other CPUs.

Any speedup/slowdown because of redesign? Still the same levels of 
performance as you posted in your blog?

Yes, about the same.  Depends on if your CPU is hyperthreaded.  The 
problem there is that removing instructions (making the opcodes more 
efficient) actually has slowed it down a bit (like here on my system).

There is one big change yet to make: security.

to better support OS-X? So Internally you will switch to VM? Well, 
sorry for such questions, it is not just my level of knowledge - 
too low level :-)

So now someone can start thinking of writing JIT for rebcode, right? 
:-)

btw - would it (technically) make sense to provide interface to internal 
representation of datatypes? Dunno, just very primitive question, 
maybe it can't even technically work that way, but I thought that 
using technique as a rebcode, theoretically we could produce our 
own natives. Think of 'remove-each as an example. You had to provide 
us with one. I thought that if it would be possible to access e.g. 
block from within the rebcode, do some operations, that such functions 
could be done. Is that nonsense? :-)

Maybe we could rewrite some mezzanines then and have them more fast, 
but as I said - I am not even sure I know what I talk about :-)

I've though a lot about internal access to datatypes, but the problem 
is that they change. For example, the 2.7.0 core kernel changes the 
internal id's for 80% of the datatypes.

So, the only way to do it would be to isolate them (datatype identifiers) 
via a lookup table.

wasn't it planned for so called language plug-ins some time ago?

Yes, in fact it was the plugin design that made the problem clear.

So that ppl could write own components? Either in external language/libraries, 
or using VM?

The more I worked on it, the more problems that came up.

A better approach is to use VM, and eventually JIT to native.

Then, if we come up with a datatype definition method, it may be 
possible to allow user created datatypes.

Yes, VM sounds good, but without internal access to datatypes? Dunno, 
will have to look into examples. Can't imagine manipulating block 
datatype for e.g. using VM :-)

But, there would be many rules, because the user must be aware of 
GC and such.

Gabriele did something like that iirc ...

Blocks are not very useful at VM level. Mostly strings, and the new 
Vector datatype.

Vector? AGG related?

note about the new ASM: it has an iterative rewriting engine, so 
you can define rewriting rules and basically create your own assembler/compiler.

with it, i can write things like this:

f: rebcode [x y /local res] [
    res: x * x + (y * y)
    sqrt res
    return res
]

the x * x + (y * y) line is compiled to rebcode by the assembler, 
provided you give it the rules to do so :)

think of it as the macro expander in LISP, but more powerful (based 
on parse rules, so you can "expand" any dialect)

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

Contains low level fixes and Gabriele's new assembler.

Both CORE and VIEW versions included.

Pekr: vector as a word for 1D array.

For example, vectors will let you create an optimal array of integers 
(unlike blocks).

Mostly useful for specific algorithms and use in rebcode VM.

But, note, not currently functional.

link is broken

rebcode8.zip (there's a typo above)... but, wait, we found a couple 
bugs ;)

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

;you can try:
do http://www.colellachiara.com/soft/Misc/julia.r

Carl:for some reason IE can not open/save rebcode9.zip-the page just 
gives me a blank icon ? But Firefox does work ! :)

Very nice Gabriele :)

Thanks for the answers to some of my questions! In summary:

- The set-word notation for setting variables doesn't seem to work 
any more, and the reason for the change to the set* opcodes is increased 
speed.

- BRAW is computed goto, but it is yet unclear what the value of 
the word is supposed to be. I'll test.

After testing and some guesses I figured out that the rebcode dialect 
is statement-based, although it can be converted from expression-based 
by the aforementioned rewrite rules. Also, the | in the declaration 
of opcode syntax refers to alternate data types, so that:
    skip: [word! integer! | word!]

means that skip takes a word! as its first argument and an integer! 
or a word! in its second argument.

After some digging, it seems that the inner block goto label problem 
has been solved. I'm not sure where Gabriele's user defined rewrite 
rules are to be set, but I'm still looking.

The syntax check in Gabriele's assembler seems solid at first glance 
- it seems to be automatically generated from the system/internal/rebcodes 
object, or both generated from the same source data.

There may still be ways to crash the VM using semantic errors (type 
mismatch and such). Testing...

So far, argument words with the wrong type of values assigned to 
them just seem to cause the opcodes to be skipped without complaint. 
Certainly better than crashing, but it could lead to the kind of 
errors that would be difficult to find without extensive unit testing 
or a type inferencer. Still, I'm pleased.