World: r3wp

Does the | integer! in the rebcode spec refer to an argument type 
or a return type?

If it is a return type, does the operation still modify its first 
argument when the return value is used?

Given the addition of the set, seti and setd opcodes, does the set-word! 
notation for setting variables still work?

The new syntax of do in the tests and opcodes is not reflected in 
the treatment of do in the assembler.

The new do seems to take a word before the block, presumably to catch 
the return value, but the assembler stage of removing the do blocks 
for binding doesn't take that word into account.

If the braw opcode is a computed goto, does this mean the label words 
can be referenced to get their offset value? Or is this just for 
compilers?

I would LOVE to add a syntax check to the assembler, if only I knew 
the current syntax. I also have an idea on handling of nested labels 
better.

The syntax check would allow such errors to be caught at rebcode 
creation time, rather than have it just crash REBOL with no error 
message at runtime.

Can you branch out of a block to an enclosing block?

The assembler comment says no, but it hasn't been updated to reflect 
the other changes in syntax for test 2.

Sorry for the mass of questions, rather than just testing for myself 
:)

I have to go elsewhere for a while, and can pick up the discussion 
later...

Do has been fixed.  Also Gabriele has been working on better assembler.

BRAW - yes computed goto.

BTW, code for everything is in system/internal object.

We will be doing another update very soon with new asm and various 
fixes.

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.